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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is applicable to User Equipment (UEs), Application Servers (AS), MSC Servers providing IMS 
Service Continuity capabilities. Emergency Access Transfer Function (EATF), Access Transfer Control Function 
(ATCF). 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPPTR 21.905 [1]. 

Alerting phase: Refers to a SIP session for which all possibly existing dialogs created by the SIP INVITE request 
initiating the session are early dialogs, for which no final SIP response has been received yet and for which SIP 180 
(Ringing) response has already been received in an existing early dialogs. 

Dynamic STI: An STI dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Additional transferred session SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and 
which is used during PS-CS access transfer with the MSC Server assisted mid-call feature. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URI. The static STI is used for CS-PS transfer when dynamic STI is unavailable. 

PS to PS STI: An STI configured in SC UE either as a SIP URI or as an E. 164 number in tel URI or SIP URI 
representation of tel URI. The PS to PS STI is used for PS to PS access transfer. 

Speech media component: SDP media component of audio media type with codec suitable for conversational speech. 
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Active speech media component: speech media component which has "recvonly" or "sendrecv" directionality at the 
SC UE or at the MSC server serving the SC UE. 

Inactive speech media component: speech media component which has "sendonly" or "inactive" directionality at the 
SC UE or at the MSC server serving the SC UE. 

Active video media component: video media component which has "recvonly" or "sendrecv" directionality at the SC 
UE or at the MSC server serving the SC UE. 

Inactive video media component: video media component which has "sendonly" or "inactive" directionality at the SC 
UE or at the MSC server serving the SC UE. 

ATCF URI for originating requests: A URI of the ATCF where the ATCF receives requests sent by the served UEs. 

ATCF URI for terminating requests: A URI of the ATCF where the ATCF receives requests targeted to the served 
UEs. 

ATCF management URI: A URI hosted by the ATCF where the ATCF performing the role of a UAS receives SIP 
requests for ATCF management (e.g. SIP MESSAGE requests containing the PS to CS SRVCC related information). 
The ATCF management URI is routable via the I-CSCF in the network where the ATCF is located using the same 
routing mechanism as used for Public Service Identities hosted by an AS. 

Registration Path: The set of Path header field values and the set of Service-Route header field values created by 
successful completion of the SIP REGISTER transaction. 

SRVCC-related information: Information required by the ATCF to perform PS to CS SRVCC transfer or CS to PS 
SRVCC transfer or both. It is provided in the MIME body as defined in annex D.3. 

UE information for CS to PS SRVCC: Session description containing speech media component that will be used by 
the ATGW to send media to the SC UE during the CS to PS SRVCC access transfer. 

ATGW information for CS to PS SRVCC: Session description containing speech media component that will be used 
by the SC UE to send media to the ATGW during the CS to PS SRVCC access transfer. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 

Access Transfer Control Function (ATCF) 

Access Transfer Gateway (ATGW) 

Access Transfer Update - Session Transfer Identifier (ATU-STI) 

Emergency Session Transfer Number for SR VCC (E-STN-SR) 

Home Leg 

Local Operating Environment 

Remote Leg 

Serving LegSession Transfer Identifier for reverse SRVCC (STI-rSR) 

Source Access Leg 

Target Access Leg 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 

CS call 
CS media 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [67] apply: 
Initial filter criteria 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [15] apply: 
PoUcy and Charging Rule Function (PCRF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 
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Correlation MSISDN 

IP Multimedia Routeing Number (IMRN) 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

For the purposes of the present document, the following terms and definitions given in IETF RFC 5012 [16] apply: 
Emergency service URN 

For the purposes of the present document, the following terms and definitions given in IETF RFC 4353 [55] apply: 

Conference 
Conference URI 
Focus 
Participant 

For the purposes of the present document, the following terms and definitions given in IETF RFC 3264 [58] apply: 
Directionality 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [63] apply: 
ICS user 

For the purposes of the present document, the following terms and definitions given 3GPP TS 24.229 [2] apply: 

Authorised Resource-Priority header field 
Temporarily Authorised Resource-Priority header field 

NOTE: Within the present specification, a Temporarily Authorised Resource-Priority header field can be applied 
to handling of originating requests in the ATCF. 

For the purposes of the present document, the following terms and definitions given 3GPP TS 29.274 [70] apply: 

Allocation/Retention Priority (ARP) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [I]. 

EATF Emergency Access Transfer Function 

E-STN-SR Emergency Call Session Transfer Number - Single Radio 

E-SR-VCC Emergency Single Radio Voice Call Continuity 

C-MSISDN Correlation MSISDN 

IMRN IP Multimedia Routing Number 

SC Service Continuity 

sec Service Centralization and Continuity 

SM Session Management 

SRVCC Single Radio Voice Call Continuity 

STI Session Transfer Identifier 

STI-rSR Session Transfer Identifier for reverse SRVCC 

STN Session Transfer Number 

STN-SR Session Transfer Number - Single Radio 

vSRVCC Single Radio Video Call Continuity 
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4 Overview of IP Multimedia (IIVI) Core Network (CN) 

subsystem Service Continuity 

4.1 General 

In general, IMS Service Continuity provides the capability of continuing ongoing communication sessions with multiple 
media across different access networks. The main need for such continuity arises because user equipments (UEs) with 
multimedia capabilities can move across a multiplicity of different access networks. 

NOTE: The capability of continuing ongoing communication sessions as a collaboration between different user 
equipments (UEs) is described in 3GPP TS 24.337 [64]. 

The following procedures are provided within this document: 

procedures for registration in IM CN subsystem are specified in clause 6; 

procedures for call origination are specified in clause 7; 

procedures for call termination are specified in clause 8; 

procedures for PS-CS access transfer are specified in clause 9; 

procedures for PS-PS access transfer are specified in clause 10; 

procedures for PS-PS access transfer in conjunction with PS-CS access transfer are specified in clause 11; 

procedures for PS-CS access transfer for Single Radio are specified in clause 12; 

procedures for media adding/deleting for access transfer are specified in clause 13; 

procedures for service continuity and MMTEL interactions are specified in clause 20. 
For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 

one full-duplex session with active speech or speech/video media component; and 

up to one full-duplex session with active speech or speech/video media component and up to one session with 
inactive speech or speech/video media component when the MSC Server assisted mid-call feature is supported. 

4.2 Underlying network capabilities 

4.2.1 General 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 

3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4]; 

4.2.2 PS-CS session continuity, Single Radio 

In order to allow for PS-CS session continuity. Single Radio, SRVCC procedures assume that filter criteria causes all 
sessions subject to PS to CS SRVCC to be anchored in an SCC AS as described in 3GPP TS 23.216 [5]). 

Configuration of QoS assignment for PS to CS SRVCC as defined in 3GPP TS 23.203 [65] and 3GPP TS 23.107 [66] 
need to be aligned with the initial filter criteria and SCC AS determination that a session is subject to SR-VCC as 
defined in 3GPP TS 23.216 [5]). 
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In order to allow for PS-CS session continuity, Single Radio, vSRVCC procedures assume that filter criteria causes all 
sessions subject to vSRVCC to be anchored in an SCC AS as described in 3GPP TS 23.216 [5]). 

Configuration of QoS assignment for vSRVCC as defined in 3GPP TS 23.203 [65] needs to be aligned with the initial 
filter criteria and SCC AS determination that a session is subject to vSRVCC as defined in 3GPP TS 23.216 [5]). 

When SRVCC enhanced with ATCF is used, the SRVCC and vSRVCC procedures assume that all sessions subject to 
SRVCC and vSRVCC are anchored in the same ATCF. 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for access transfer will be configured with a static STI, in accordance 
with subclause 5.11 in 3GPP TS 24.216 [5]; a static STN in accordance with subclause 5.12 in 

3GPP TS 24.216 [5]. The static STI is used by the SC UE to perform CS to PS access transfer when no 
dynamically assigned STI is provided to the UE over the CS domain (e.g. when the SC UE does not support ICS 
capabiHties as defined in 3GPP TS 24.292 [4]). The static STN is used by the SC UE to perform PS to CS access 
transfer when no service control signalling path as specified in 3GPP TS 24.292 [4] is available; a PS to PS STI 
URI in accordance with subclause 5.30 in 3GPP TS 24.216 [5]. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 
subsystem; or 

the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 

c) the SCC AS is configured to be reachable using: 

- the STN-SR allocated to the SCC AS; 

- the additional transferred session SCC AS URI allocated to the SCC AS; 

- the additional transferred session SCC AS URI for PS to CS SRVCC allocated to the SCC AS; 

- the additional transferred session SCC AS URI for CS to PS SRVCC allocated to the SCC AS; 

- the ATU-STI for PS to CS SRVCC allocated to the SCC AS; 

- the ATU-STI for CS to PS SRVCC allocated to the SCC AS; and 

- the PS to PS STI for PS to PS access transfer. 

d) the ATCF is configured to be reachable using: 

- the STN-SR allocated to the ATCF; 

the ATCF URI for originating requests allocated to the ATCF; 

the ATCF URI for terminating requests allocated to the registration path; and 

ATCF management URI allocated to the ATCF. The ATCF management URI is included in the g.3gpp.atcf- 
mgmt-uri feature-capability indicator that the ATCF includes in a Feature-Caps header field in the SIP 
REGISTER request. 

e) the MSC server enhanced for ICS and supporting CS to PS SRVCC is configured to be reachable (in addition to 
configuration in 3GPP TS 24.292 [4]) using: 

the MSC URI for redirected terminating sessions allocated to the registration path; and 
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the MSC server management URI allocated to the MSC server. 

4.4 Support of session continuity in enterprise scenarios 

Session continuity can be applied where hosted enterprise services are supported as documented in 

ETSI TS 182 024 [76] the UE registers with the S-CSCF in the normal manner, and the procedures of this document 

can be used with an SCC-AS in the home network. 

Where the UE is supported by an application server in the enterprise, any enterprise UE requiring service continuity to 
be supported by the public network requires an SCC AS in the home network, and therefore registration with an S- 
CSCF in the home network. 

4.5 Guidelines for use of media feature tags 

NOTE: When the values appropriate for use with a media feature tag are of string type, then when included in 

Contact, Accept-Contact or Reject-Contact header fields, the value of the media feature tag is preceded by 
"<" and followed by ">" according to IETF RFC 3840 [53] and IETF RFC 3841 [78]. 

5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPP TS 23.237 [9]). 

5.2 User Equipment (UE) 

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE: 

according to subclause 6.2 for registration of the UE in the IM CN subsystem; and 

dependent on the desired functionality, one or more of the procedures according to subclause 6A.2, 
subclause 6.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, subclause 12.2, 
subclause 13.2 and subclause 20.1. 



5.3 Application Server (AS) 



To be compliant with access transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 6.3, subclause 6A.4, subclause 6A.4.4, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, 
subclause 11.3, subclause 12.3, subclause 13.3 and subclause 20.1. 

The SCC AS also handles SDP media description conflicts according to subclause 6A.5. 

5.4 MSC server 

An MSC server can be compliant with PS to CS SRVCC session transfer procedures as described in this document. 

In order to be compliant with PS to CS SRVCC session transfer procedures as described in this document: 

an MSC server using SIP interface to initiate the session transfer shall provide the UA role as defined for a 
MGCF in annex A of 3GPP TS 24.229 [2] and the role of an MSC server enhanced for PS to CS SRVCC usinj 
SIP interface as described in subclause 12.6.1.1; or 

an MSC server shall provide the role of an MSC server enhanced for ICS as specified in subclause 12.4.0. 
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In order to be compliant with vSRVCC session transfer procedures as described in this document, the MSC server shall 
be: 

compliant with the PS to CS SRVCC session transfer procedure specified in subclause 12.6.1.1 and additionally 
provide the functionality to support vSRVCC, as described in subclause 12.6.1.2; or 

compliant with the PS to CS SRVCC session transfer procedure specified in subclauses 12.4.0 and additionally 
provide the functionality to support vSRVCC, as described in subclause 12. 4. OB. 

An MSC server can be compliant with the access transfer procedures for the MSC server assisted mid-call feature as 
described in this document. 

In order to be compliant with the access transfer procedures for the MSC server assisted mid-call feature as described in 
this document, the MSC server shall: 

provide the role of an MSC server enhanced for ICS as described in subclause 6.4 and subclause 9.4 and 
additionally provide the functionality described in subclause 9.5; 

provide the role of an MSC server enhanced for ICS as described in subclause 12.4.0, and additionally provide 
the functionality described in subclause 12.4A; or 

provide the role of an MSC server enhanced for PS to CS SRVCC using a SIP interface as described in 
subclause 12.6.1.1, and additionally provide the functionality described in subclause 12. 4A. 

In order to enable the UE to remove/add participants from/to an IMS conference call after the access transfer, the MSC 
Server supporting the MSC server assisted mid-call feature shall provide the role of an MSC server enhanced for ICS. 

An MSC server can be compliant with the PS to CS access transfer for alerting calls procedures as described in this 
document. 

In order to be compliant with the PS to CS access transfer for alerting calls procedures as described in this document, 
the MSC server shall: 

provide the role of an MSC server enhanced for ICS as described in subclause 12.4.0 or subclause 12.4. OB, and 
additionally provide the functionality described in subclause 12.6.3; or 

provide the role of an MSC server enhanced for SRVCC using a SIP interface as described in subclause 12.6. 1 
and additionally provide the functionality described in subclause 12.6.3. 

The MSC server also handles SDP media description conflicts according to subclause 6A.5. 

5.5 EATF 

To be compliant with access transfer in this document, the EATF shall act as B2BUA and: 

extract charging information as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.2; 

identify the served user as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.3A.2; 

map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by EATF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

handle P-Charging-Vector header as specified for an routeing AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

implement the role of an EATF according to subclause 7.4 and subclause 12.5. 

The EATF also handles SDP media description conflicts according to subclause 6A.5. 

5.6 Access Transfer Control Function (ATCF) 

To be compliant with access transfer in this document, the ATCF shall: 
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1) provide the proxy role as defined in 3GPP TS 24.229 [2], with the exceptions and additional capabilities as 
described for the ATCF in subclause 6.5, subclause 6A.3, subclause 7.5, subclause 8.4, and subclause 12.7.2.4; 

2) provide the B2BUA functionality with the exceptions and additional capabilities as described for the ATCF in 
subclause 12.7.2.2. When providing the B2BUA functionality, the ATCF shall provide the UA role as defined in 
3GPP TS 24.229 [2] and additionally shall: 

a. map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by ATCF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

b. pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

c. transparently forward received Contact header field; and 

3) if decided to anchor the media in ATGW according to operator policy: 

NOTE: At this point, ATCF interacts with ATGW to provide information needed in the procedures below. The 
details of interaction between ATCF and ATGW are out of scope of this document. 

a. upon receiving an SDP offer or answer included in a SIP message sent by the served UE within the dialog, 
replace the SDP in the received SIP message with updated SDP provided by ATGW; and 

b. upon receiving an SDP offer or answer included in a SIP message sent by remote UE within the dialog, 
replace the SDP in the received SIP message with updated SDP provided by ATGW. 

The ATCF also handles SDP media description conflicts according to subclause 6 A. 5. 

5.7 Access Transfer Gateway (ATGW) 

The functionality of the ATGW is specified in 3GPP TS 23.237 [9]. 

6 Roles for registration in the IIVI CN subsystem for 

service continuity 

6.1 Introduction 

Void. 

6.2 SC UE 

6.2.1 Distinction of requests 

The SC UE needs to distinguish the following initial SIP requests: 

1) SIP MESSAGE requests with the P-Asserted-Identity header field containing the STI-rSR. In the procedures 
below, such requests are known as "SIP MESSAGE requests with ATGW information for CS to PS SRVCC". 

6.2.2 General 

Prior to performing IMS registration, if the SC UE supports ICS capabilities as defined in 3GPP TS 24.292 [4], the SC 
UE shall check that IMS service continuity using ICS is enabled. An indication that SC using ICS is enabled or disabled 
can be found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]). 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 

subsystem. 

If SC using ICS is enabled then prior to making use of ICS procedures, the SC UE shall follow the procedures specified 
in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 
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The SC UE shall include the gjgpp.accesstype media feature tag as described in subclause B.3 of 3GPP TS 24.292 [4] 
in the Contact header field of the SIP REGISTER request. 

If the SC UE supports the CS to PS SRVCC, the SC UE shall include the g.3gpp.cs2ps-srvcc media feature tag in the 
Contact header field of the SIP REGISTER request. 

Upon receiving a SIP 2xx response to the REGISTER request and if the SIP 2xx response contains a Feature-Caps 
header field with the g.3gpp.atcf feature-capability indicator and with the g.3gpp.cs2ps-srvcc feature-capability 
indicator, the SC UE shall: 

1) determine STI-rSR as the value of the g.3gpp.cs2ps-srvcc feature-capability indicator in the Feature-Caps header 
field containing both the g.3gpp.atcf feature-capability indicator and the g.3gpp.cs2ps-srvcc feature-capability 
indicator; and 

2) store the determined STI-rSR. 

If the SC UE supports the PS to PS access transfer and the PS to PS STI URI is configured in the SC UE, the SC UE 
shall include the g.3gpp.pstop-sti media feature tag in the Contact header field of the SIP REGISTER request. 

6.2.3 SC UE receiving tine ATGW information for CS to PS SRVCC 

If the SC UE supports the CS to PS SRVCC, upon receiving a SIP MESSAGE request with ATGW information for CS 
to PS SRVCC, if the SIP MESSAGE request is acceptable for the UE, in addition to sending 2xx response to the SIP 
MESSAGE request, the SC UE shall; 

1) determine the ATGW information for CS to PS SRVCC as the application/SDP MIME body of the SIP 
MESSAGE request; 

2) store the determined ATGW information for CS to PS SRVCC; 

3) generate the UE information for CS to PS SRVCC as an SDP answer to the determined ATGW information for 
CS to PS SRVCC according to IETF RFC 3264 [58] and 3GPP TS 24.229 [2]; 

4) store the generated UE information for CS to PS SRVCC; and 

5) send a SIP MESSAGE request according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP MESSAGE 
request with: 

A) Request-URI containing the determined STI-rSR; 

B) Content-Disposition header field with value "render"; and 

C) application/sdp MIME body containing the generated UE information for CS to PS SRVCC. 

6.3 sec AS 

6.3.1 General 

The sec AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third- 
party SIP REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabilities supported by the user registered UE(s), including the used IP-CAN(s), other than that is 
specified in 3GPP TS 29.328 [6], e.g. the UE PS to CS SRVCC capabiHty and 3GPP access networks" 
information related to T-ADS. 
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When the SCC AS obtains the registration state information including an Correlation MSISDN using one of the above 
procedures, the SCC AS shall determine if the registration state information is associated with ongoing CS call by 
matching the Correlation MSISDN against the: 

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE 
request was due to static STN, where the SIP INVITE request was stored according to subclause 7.3.1; or 

b) tel URI in the Request-URI when the SIP INVITE request was due to processing unregistered filter criteria, 
where the SIP INVITE request was stored according to subclause 7.3.1. 

If the registration state information is associated with an ongoing call the contents of the registration state information 
shall be bound to the ongoing CS call session identifier. 

6.3.2 Triggers for the SCC AS providing information to ATCF 

This subclause applies for a contact address (or a registration flow, if multiple registration mechanism is used) in the 
registration state information obtained by SCC AS: 

1) which is registered by the UE: 

A) in E-UTRAN, UTRAN and GERAN access networks; and 

NOTE: The access network where the UE performed registration can be found in the P- Access-Network-Info 
header field of the SIP REGISTER request. 

B) for a private user identity associated with a C-MSISDN; and 

2) where the SIP REGISTER request contained a Feature-Caps header field containing the g.3gpp.atcf feature- 
capability indicator. 

The SCC AS shall identify the ATCF URI for terminating requests of the related ATCF as the URI in the g.3gpp.atcf- 
path feature-capability indicator included in a Feature-Caps header field of the SIP REGISTER request that created the 
binding. 

The SCC AS shall store the feature-capability indicators indicated in the Feature-Caps header field containing the 
g.3gpp.atcf feature-capability indicator until the binding is removed. 

The SCC AS shall determine that PS to CS SRVCC is usable for the UE if the UE PS to CS SRVCC Capability (see 
3GPP TS 29.328 [6]) of the UE has value UE-SRVCC-CAP ABILITY-SUPPORTED and if the private user identity of 
the UE has associated STN-SR (see 3GPP TS 29.328 [6]). 

If SCC AS supports CS to PS SRVCC, the SCC AS shall also determine whether the CS to PS SRVCC is usable for the 
private user identity of the UE as described in subclause 6.3.4. 

When the SCC AS becomes aware of a new contact address (or new registration flow, if multiple registration 
mechanism is used) that fulfils the above criteria and: 

- PS to CS SRVCC is usable for the UE; or 

- the SCC AS supports CS to PS SRVCC and CS to PS SRVCC is usable for the UE; 

the SCC AS shall perform actions as described in subclause 6.3.3 with the related ATCF. 

When the SCC AS becomes aware that, for a UE which registered the contact address (or registered the registration 
flow, if multiple registration mechanism is used) that fulfils the above criteria that: 

1) PS to CS SRVCC was usable and PS to CS SRVCC is not usable now; 

2) PS to CS SRVCC was not usable and PS to CS SRVCC is usable now; or 

3) the SCC AS supports CS to PS SRVCC and: 

A) CS to PS SRVCC was usable and CS to PS SRVCC is not usable now; or 

B) CS to PS SRVCC was not usable and CS to PS SRVCC is usable now; 
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then the SCC AS shall provide the SRVCC-related information to the related ATCF as described in subclause 6.3.3. 

6.3.3 SCC AS providing tine PS to CS SRVCC related information to tine 
ATCF 

In order to provide the PS to CS SRVCC related information to the ATCF, the SCC AS shall perform the role of an AS 
acting as originating UA according to 3GPP TS 24.229 [2] subclause 5.7.3 and shall send a SIP MESSAGE request 
populated as follows: 

1) the Request-URI set to the ATCF management URI of the ATCF associated with the registration path (or 
registration flow, if multiple registration mechanism is used); 

NOTE 1: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature- 
capability indicator that is included in a Feature-Caps header field of the SIP REGISTER request which 
the S-CSCF received from the UE using the method to obtain registration state information described in 
step a) of subclause 6.3.1. 

2) the P-Asserted-Identity header field containing the identity of the SCC AS; and 

3) the application/vnd.3gpp.SRVCC-infoH-xml MIME body as defined in annex D.3. 

NOTE 2: The ATCF URI for terminating calls of the registration path (or registration flow, if multiple registration 
mechanism is used) is contained in the g.3gpp.atcf-path feature-capability indicator that is included in a 
Feature-Caps header field of the SIP REGISTER request which the S-CSCF received from the UE using 
the method to obtain registration state information described in step a) of subclause 6.3.1. 

6.3.4 Triggers for tine SCC AS providing information to MSC server 

If the SCC AS supports the CS to PS SRVCC, this subclause applies for a contact address in the registration state 
information obtained by SCC AS: 

1) which is registered for a private user identity associated with an MSC server enhanced for ICS according to 
3GPP TS 23.003 [12], subclause 20.3.3; 

2) which is registered for a private user identity associated with a C-MSISDN; and 

3) where the g.3gpp.cs2ps-srvcc media feature tag and the g.3gpp.path media feature tag are associated with the 
contact address. 

The SCC AS shall determine that the CS to PS SRVCC is usable if: 

1) a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) 
associated with the same C-MSISDN as the private user identity belonging to the MSC server exists; 

2) a binding of a contact address exists for the private user identity of the UE: 

A) such that the g.3gpp.cs2ps-srvcc media feature tag is associated with the contact address of the UE; and 

B) such that SIP REGISTER request which registered the binding contained a Feature-Caps header field with 
the g.3gpp.atcf feature-capability indicator and with g.3gpp.cs2ps-srvcc media feature tag; 

3) the CS to PS SRVCC capability indication is indicated for the private user identity of the UE; and 

4) the private user identity of the UE has the CS to PS SRVCC allowed indication in the subscription data. 

When the SCC AS becomes aware of a new contact address that fulfils the above criteria and the CS to PS SRVCC is 
usable, the SCC AS shall perform actions as described in subclause 6.3.5 for the contact address. 

When the SCC AS becomes aware that, for a contact address: 

1) the CS to PS SRVCC was usable and the CS to PS SRVCC is not usable now; or 

2) the CS to PS SRVCC was not usable and the CS to PS SRVCC is usable now; 

then the SCC AS shall perform actions as described in subclause 6.3.5 for the contact address. 
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6.3.5 sec AS providing tine CS to PS SRVCC information to tine MSC 
server 

If the sec AS supports the CS to PS SRVCC, in order to provide the CS to PS SRVCC information to a contact 
address registered by the MSC server, the SCC AS shall perform the role of an AS acting as originating UA according 
to 3GPP TS 24.229 [2] subclause 5.7.3 and shall send a SIP MESSAGE request populated as follows: 

1) the Request-URI set to an IMS public user identity registered at the contact address; 

2) the P-Asserted-Identity header field containing the identity of the SCC AS; 

3) the Accept-Contact header field with the g.3gpp.path media feature tag with value of the g.3gpp.path media 
feature tag associated with the contact address and with "explicit" and "require"; and 

4) the application/vnd.3gpp.srvcc-ext+xml MIME body. 

NOTE 1: The MSC URI for terminating calls of the contact address is contained in the g.3gpp.path media feature 
tag that is included in a Contact header field of the SIP REGISTER request which the S-CSCF received 
from the UE using the method to obtain registration state information described in step a) of 
subclause 6.3.1. 

6.4 MSC server 

6.4.1 Distinction of requests 

The MSC server needs to distinguish the following initial SIP requests: 

1) SIP MESSAGE requests with the Accept-Contact header field containing the g.3gpp.path media feature tag and 
with the application/vnd.3gpp.srvcc-ext+xml MIME body. In the procedures below, such requests are known as 
"SIP MESSAGE requests with MSC information for CS to PS SRVCC". 

6.4.2 General 

If the MSC server: 

provides the role of an MSC server enhanced for ICS; and 

determines that the served user is an ICS user; 
then in addition to the procedures specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] the MSC server shall: 

1) if the MSC server supports the MSC server assisted mid-call feature, include the g.3gpp. mid-call media feature 
tag (as described in annex C) in the Contact header field of the SIP REGISTER request; and 

2) if the MSC server supports the CS to PS SRVCC: 

A) include the g.3gpp.cs2ps-srvcc media feature tag in the Contact header field of the SIP REGISTER request; 
and 

B) include the g.3gpp.path media feature tag in the Contact header field of the SIP REGISTER request with 
value uniquely identifying the registration path. 

6.4.3 MSC server receiving the MSC information for CS to PS SRVCC 

If the MSC server supports the CS to PS SRVCC, upon receiving SIP MESSAGE requests with MSC information for 
CS to PS SRVCC, the MSC server shall: 

1) if the URI in the P-Asserted-Identity header field of the SIP MESSAGE request does not identify an SCC AS 
authorised to provide the CS to PS SRVCC information, reject the request with SIP 403 (Forbidden) response 
and do not continue with the remaining steps; and 
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NOTE: in this version of specification, the URIs of SCC ASs authorised to provide PS to CS SRVCC information 
need to be specified in the roaming agreement. 

2) bind the CS to PS SRVCC information received in the application/vnd.3gpp.srvcc-ext+xml MIME body of the 
SIP MESSAGE request to the contact address. 

6.5 Access Transfer Control Function (ATCF) 

6.5.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

1) SIP REGISTER requests with the ATCF URI for originating requests in the topmost Route header field. In the 
procedures below, such requests are known as "SIP REGISTER request originated by a UE". 

2) SIP MESSAGE requests with the ATCF management URI in the Request-URI and: 

A. not containing any Route header field; or 

B. containing a URI in the topmost Route header field other than the ATCF URI for originating requests and 
other than the ATCF URI for terminating requests. 

In the procedures below, such requests are known as "SIP MESSAGE requests with the PS to CS SRVCC 
related information". 

3) SIP MESSAGE requests with the STI-rSR allocated by ATCF in the Request-URI and with the ATCF URI for 
originating requests in the topmost Route header field. In the procedures below, such requests are known as "SIP 
MESSAGE requests with UE information for CS to PS SRVCC". 

6.5.2 Registration related procedures in the ATCF 

Upon receiving a SIP REGISTER request originated by a UE, the ATCF shall: 

1 . if ATCF decides to include itself for access transfer of sessions according to operator policy: 

NOTE 1 : An example of the operator policy is that the ATCF is included in the signalling path only when the UE 
registers over the E-UTRAN, UTRAN or GERAN access networks. 

A. generate a unique ATCF URI for terminating requests such that the registration path (or registration flow, if 
multiple registration mechanism is used) can be determined for terminating requests; 

NOTE 1 A: One possible construction method is to set the user portion of the ATCF URI for terminating requests 
to the URI of the most bottom Path header field of the SIP REGISTER request. 

B. insert a Path header field with the generated ATCF URI for terminating requests; 

C. insert a Feature-Caps header field with: 

a. the g.3gpp.atcf feature-capability indicator containing the STN-SR allocated to ATCF included as 
described in IETF RFC 6809 [60]; 

b. the g.3gpp.atcf-mgmt-uri feature-capability indicator containing the ATCF management URI included as 
described in IETF RFC 6809 [60]; 

c. the g.3gpp.atcf-path feature-capability indicator with value containing the generated ATCF URI for 
terminating requests as described in IETF RFC 6809 [60]; 

d. if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which 
are in the same network as the ATCF, support the MSC server assisted mid-call feature: 

- the g.3gpp. mid-call feature-capabihty indicator; 

e. if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which 
are in the same network as the ATCF, support the SRVCC for calls in alerting phase: 
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the g.3gpp.srvcc-alerting feature-capability indicator; and 

f. if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature 
tag and if the ATCF supports the CS to PS SRVCC: 

the g.3gpp.cs2ps-srvcc feature-capability indicator containing the STI-rSR allocated by ATCF; 

2. if the ATCF is located in the visited network and local policy requires the application of IBCF capabilities in the 
visited network towards the home network select an exit point of the visited network and forward the request to 
that entry point; 

NOTE 2: The list of the exit points can be either obtained as specified in RFC 3263 [72] or provisioned in the 
ATCF. 

3. if the ATCF is located in the visited network and local policy does not require the application of IBCF 
capabilities in the visited network towards the home network select an entry point of the home network and 
forward the request to that entry point; 

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [72] or provisioned in the 
ATCF. The entry point can be an IBCF or an I-CSCF. 

4. if the ATCF is located in the home network select an I-CSCF of the home network and forward the request to 
that I-CSCF; and 

NOTE 4: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [72] or provisioned in the ATCF. 

5. If the ATCF fails to forward the SIP REGISTER request to any entry point, the ATCF shall send back a SIP 504 
(Server Time-Out) response, in accordance with the procedures in RFC 3261 [19]. 

Upon receiving a SIP 2xx response to the SIP REGISTER request originated by a served UE and if ATCF decided to 
include itself for access transfer of sessions according to operator policy, the ATCF shall: 

1) update the S-CSCF Service-Route URI bound to the registration path (see subclause 6A.3.1) identified by the 
ATCF Path URI; and 

NOTE 5: The ATCF Path URI is the URI which the ATCF inserted in the Path header field of to the SIP 
REGISTER request. 

NOTE 6: The S-CSCF Service-Route URI is the URI in the most bottom Service-Route header field of the SIP 2xx 
response to the SIP REGISTER request. 

2) if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature tag and 
if the ATCF supports the CS to PS SRVCC: 

A) for the registration path, which has the ATCF Path URI matching the URI which the ATCF inserted in the 
Path header field of to the SIP REGISTER request: 

a) set the route set towards the SC UE bound to the registration path (see subclause 6A.3. 1) to the Path 
header fields in the received 2xx response preceding the ATCF Path URI; and 

b) set the contact address of the SC UE bound to the registration path (see subclause 6A.3.1) to the Contact 
header field of the SIP REGISTER request; 

3) insert a Feature-Caps header field with: 

A) the g.3gpp.atcf feature-capability indicator containing the STN-SR allocated to ATCF included as described 
in IETF RFC 6809 [60]; and 

B) if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature tag 
and if the ATCF supports the CS to PS SRVCC: 

a) the g.3gpp.cs2ps-srvcc feature-capability indicator containing the STI-rSR allocated by ATCF. 

6.5.3 ATCF receiving tlie SRVCC-related information 

Upon receiving SIP MESSAGE request with the SRVCC-related information, the ATCF shall: 
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1) if the URI in the P-Asserted-Identity header field of the SIP MESSAGE request does not identify an SCC AS 
authorised to provide the SRVCC-related information, reject the request with SIP 403 (Forbidden) response and 
do not continue with the remaining steps; 

NOTE: in this version of specification, the URIs of SCC ASs authorised to provide SRVCC-related information 
need to be specified in the roaming agreement. 

2) update the SRVCC-related information bound to the registration path(s) (see subclause 6A.3.1) with information 
in the application/vnd.3gpp.SRVCC-infoH-xml MIME body of the SIP MESSAGE request; 

3) determine session(s) established using the registration path(s) (see subclause 6A.3.1) whose SRVCC-related 
information were updated by the SRVCC-related information received in the SIP MESSAGE request and 
associate those session(s) with the SRVCC-related information bound to the registration path(s); and 

4) for each registration path in the SRVCC-related information received in the SIP MESSAGE request: 

A) if: 

a) the ATCF indicated the support of the CS to PS SRVCC when handling the SIP REGISTER request 
establishing the registration path; 

b) the SRVCC-related information for the registration path contains the ATU-STI for CS to PS SRVCC; and 

c) the ATCF does not have the UE information for CS to PS SRVCC bound to the registration path; 

send the ATGW information for CS to PS SRVCC to the SC UE within the registration path using procedure 
described in subclause 6.5.4. 

6.5.4 ATCF sending the ATGW information for CS to PS SRVCC 

If the ATCF supports the CS to PS SRVCC, in order to send the ATGW information for CS to PS SRVCC to the SC 
UE within a registration path, the ATCF shall: 

1) generate the ATGW information for CS to PS SRVCC. When generating the SDP, the ATCF shall: 

A) set c-line to the unspecified address (0.0.0.0), if IPv4, or to a domain name within the ".invalid" DNS top- 
level domain as described in IETF RFC 6157 [74], if IPv6; and 

B) set port number of the media line to 9; 

2) set the ATGW information for CS to PS SRVCC bound to the registration path (see subclause 6A.3. 1) to the 
generated ATGW information for CS to PS SRVCC; and 

3) send SIP MESSAGE request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP MESSAGE 
request with: 

A) Request-URI containing the contact address of the SC UE bound to the registration path (see 
subclause 6A.3.1); 

B) Route header fields containing the route set towards the SC UE of the registration path (see 
subclause 6A.3.1); 

C) P-Asserted-Identity header field containing the STI-rSR allocated by ATCF; 

D) Content-Disposition header field with value "render"; and 

E) application/sdp MIME body containing the generated ATGW information for CS to PS SRVCC. 

6.5.5 ATCF receiving tine UE information for CS to PS SRVCC 

If the ATCF supports the CS to PS SRVCC, upon receiving SIP MESSAGE request with UE information for CS to PS 
SRVCC and if the SIP MESSAGE request is acceptable for the ATCF, in addition to sending 2xx response to the SIP 
MESSAGE request, the ATCF shall: 
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1) determine the related registration path, which is a registration path with the ATCF Path URI matching the URI in 
the top Route header field of the SIP MESSAGE request; and 

2) set the UE information for CS to PS SRVCC bound to the determined related registration path (see 
subclause 6A.3.1) to the application/sdp MIME body of the SIP MESSAGE request. 



6A Roles for General Capabilities 
6A.1 Introduction 

This clause describes the general roles for each functional entity as specified. 

6A.2 UE roles 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

selecting the access for initiating the transfer; 

determining whether to transfer full or partial media during PS-PS transfer; or 

determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 

3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall: 

1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 

3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s list of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 
access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; and 

"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node; and 

4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 
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6A.3 ATCF 

6A.3.1 SRVCC information bound to tine registration patli 

The ATCF shall keep track of existing registrations of the served UEs. Each registration path is identified by the ATCF 
Path URL 

The ATCF shall bind the following information to the registration path identified by the ATCF Path URI: 

- the S-CSCF Service-Route URI; 

- the ATU-STI for PS to CS SRVCC; and 

- the C-MSISDN. 

If the ATCF supports CS to PS SRVCC, the ATCF shall additionally bind the following information to the registration 
path identified by the ATCF Path URI: 

- the ATU-STI for CS to PS SRVCC; 
the contact address of the SC UE; 
the route set towards the SC UE; 

- the UE information for CS to PS SRVCC; and 

- the ATGW information for CS to PS SRVCC. 

When a registration of a served UE expires or is deregistered, the ATCF can remove any SRVCC-related information 
bound to the registration path. 

The ATCF shall determine that a session is established for a specific registration path: 

if the S-CSCF Service-Route URI used during the registration matches the URI in the most bottom Route header 
field of the originating initial SIP INVITE request; or 

if the ATCF Path URI used during the registration matches the URI in the top Route header field of the 
terminating initial SIP INVITE request. 

6A.4 sec AS 

6A.4.1 Common SIP message set up procedures 

This subclause describes the common procedures for setting up SIP messages sent by SCC AS. 



6A.4.2 INVITE request 



When sending SIP INVITE request towards the served user and if the session being established is anchored in SCC AS 
as described in subclause 4.2.2 then the SCC AS shall populate the SIP INVITE request with the g.3gpp.srvcc feature- 
capability indicator in a Feature-Caps header field. 



6A.4.3 INVITE response 



When sending SIP Ixx or 2xx response to the SIP INVITE request towards the served user and if the session being 
established is anchored in SCC AS as described in subclause 4.2.2 then the SCC AS shall populate the SIP response 
with: 

1) the g.3gpp.srvcc feature-capability indicator in a Feature-Caps header field; 

2) if: 
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A) the sec AS supports the PS to CS SRVCC with the MSC server assisted mid-call feature according to 
operator policy; 

B) the g.3gpp. mid-call media feature tag is included in the Contact header field of the SIP INVITE request; and 

C) the sec AS is aware: 

a) by local policy; or 

b) by ATCF indicating support of the PS to CS SRVCC with the MSC server assisted mid-call feature; 

NOTE 1: An ATCF can indicate support of the PS to CS SRVCC with the MSC server assisted mid-call feature by 
inclusion of the g.3gpp. mid-call feature-capability indicator in the Feature-Caps header field, with the 
g.3gpp.atcf feature-capability indicator, in the SIP REGISTER request that created the binding of the SC 
UE. 

that all MSC Servers in the network, where the UE is registered, which can be involved in the PS to CS 
SRVCC procedures, support the PS to CS SRVCC with the MSC server assisted mid-call feature; 

NOTE 2: SCC AS can identify the network, where the UE is registered, based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the g.3gpp. mid-call feature-capability indicator in the Feature-Caps header field containing the g.3gpp.srvcc 
feature-capability indicator; and 

3) if: 

A) the SCC AS supports the PS to CS SRVCC for calls in alerting phase according to operator policy; 

B) the g.3gpp.srvcc-alerting feature tag is included in the Contact header field of the SIP INVITE request; and 

C) the SCC AS is aware: 

a) by local policy; or 

b) by ATCF indicating support of the PS to CS SRVCC for calls in alerting phase; 

NOTE 3: An ATCF can indicate support of the PS to CS SRVCC for calls in alerting phase by inclusion of the 

g.3gpp.srvcc-alerting feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf 
feature-capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC Servers in the network, where the UE is registered, which can be involved in the PS to CS 
SRVCC procedures, support the PS to CS SRVCC for calls in alerting phase; 

NOTE 4: SCC AS can identify the network, where the UE is registered, based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the g.3gpp.srvcc-alerting feature-capability indicator in the Feature-Caps header field containing the 
g.3gpp.srvcc feature-capability indicator. 

6A.4.4 Handling of OMR specific attributes 

When an SDP offer containing OMR specific attributes specified in subclause 7.5.3 of 3GPP TS 24.229 [2] is received 
from either the source access leg or the target access leg, the SCC AS supporting OMR shall perform the actions 
specified in subclause 7.2.2 of 3GPP TS 29.079 [77]. 

When the SCC AS supporting OMR sends an SDP offer towards the remote party and if 

the SDP offer consists of several media lines merged from a source access leg and a target access leg; and 
any of the media lines contains OMR attributes; 

then the SCC AS shall recalculate the checksums as specified in subclause 5.6.3 3GPP TS 29.079 [77]. 

If the SCC AS has not changed the content of a m-line and associated attributes, an SCC AS supporting OMR shall only 
calculate the session level checksum and replace the new value in each occurrences of the "a=omr-s-cksum" attribute. 
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The the SCC AS supporting OMR shall forward the OMR specific attributes received in the SDP answer. 

NOTE: When the SCC AS does not support OMR an optimal media path created before the transfer will not be 
established again. 

6A.4.5 Target refresh request for a dialog and associated responses 

The SCC AS shall include into the Feature-Caps header field of any target refresh request and, in each Ixx or 2xx 
response to target refresh request sent to the SC UE: 

A) the g.3gpp.srvcc feature-capability indicator if the session being established is anchored in the SCC AS as 
described in subclause 4.2.2 and if the SCC AS inserted the g.3gpp.srvcc feature-capability indicator into the 
Feature-Caps header field of: 

1) the SIP INVITE request in accordance with subclause 6A.4.2; or 

2) the SIP Ixx or 2xx response to the SIP INVITE request in accordance with subclause 6A.4.3; 

B) the g.3gpp. mid-call feature-capability indicator if the SCC AS inserted the g.3gpp. mid-call feature-capability 
indicator into the Feature-Caps header field of: 

1) the SIP 2xx response to the SIP INVITE request due to originating filter criteria in accordance with 
subclause 7.3.2; 

2) the SIP INVITE request due to terminating filter criteria if the SCC AS applies the MSC Server assisted mid- 
call feature in accordance with subclause 8.3.2; 

3) the SIP 2xx response to the SIP INVITE request due to static STN if the SCC AS applies the MSC Server 
assisted mid-call feature in accordance with subclause 9.3.2A; 

4) the SIP 2xx response to the SIP INVITE request due to static STI if the SCC AS applies the MSC Server 
assisted mid-call feature in accordance with subclause 9.3.4; or 

5) the SIP 2xx response to the SIP INVITE request due to STI if the SCC AS applies the MSC Server assisted 
mid-call feature in accordance with subclause 10.3.3; and 

C) the g.3gpp.srvcc-alerting feature-capability indicator if the SCC AS inserted the g.3gpp.srvcc-alerting feature- 
capability indicator into the Feature-Caps header field of: 

1) any SIP Ixx or 2xx response to the SIP INVITE request due to originating filter criteria if the SCC AS 
applies PS to CS SRVCC for calls in alerting phase in accordance with subclause 7.3.2; or 

2) the SIP INVITE request due to terminating filter criteria if the SCC AS applies PS to CS SRVCC for calls in 
alerting phase in accordance with subclause 8.3.2. 

6A.5 SDP media description conflict between target and remote 
access leg 

When the SCC AS, the EATF or the ATCF receives an SDP offer on the target access leg, the SDP media descriptions 
on the target access leg and the remote access leg, can be in conflict. The way how the SCC AS, EATF and ATCF 
resolve the conflict is implementation dependent. 

NOTE 1 : Examples of conflicts are when, for a given media type, different IP versions are used on each access leg, 
or when the same payload type number has been assigned to different codecs on each access leg. 

NOTE 2: An example on how to solve a conflict can be that transcoding functionality is enabled by inserting an 
MRF (in case of SCC AS or EATF) or an ATGW (in case of ATCF). Another example is that 488 (Not 
Acceptable Here) response is sent with the correct SDP media description. 

When the MSC server receives a SIP 488 (Not Acceptable Here) response to an initial INVITE and an SDP body is 
present in the response, the MSC server should re-initiate the initial INVITE using the part of the received SDP media 
description that the MSC server supports. 
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7 Roles for call origination for service continuity 

7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS, 
the EATF and the ATCF. 

Further this clause specifies procedures for cases where the ATCF handles SIP requests that are not related to a call. 

7.2 SC UE 

7.2.1 General 

The SC UE shall support origination of IP multimedia sessions in the IM CN subsystem as specified in 

3GPP TS 24.229 [2]. If the SC UE supports the MSC server assisted mid-call feature, the SC UE shall include the 

g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP INVITE request. If the 

SC UE supports single radio PS to CS access transfer for calls in alerting state, the SC UE shall include the 

g. 3 gpp.srvcc- alerting media feature tag as described in annex C in the Contact header field of the SIP INVITE request. 

The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

If SC using ICS is enabled then the procedures for call origination where the SC UE is initiating calls using CS media 
are identical to that for ICS UE specified in 3GPP TS 24.292 [4]. 

When originating an emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE 
shall include the instance-id media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as 
defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request. 

7.2.2 Additional procedures with MSC server assisted mid-call feature 

Upon receiving a SIP 2xx response to the SIP INVITE request, if: 

1 . the SC UE supports the MSC server assisted mid-call feature; 

2. the g.3gpp. mid-call feature-capability indicator is included in the Feature-Caps header field received during 
session establishment; 

3. the remote UE is a conference focus; and 

NOTE: conference focus includes the isfocus media feature tag specified in IETF RFC 3840 [53] in own Contact 
header field when establishing a session. 

4. the session was created as result of the SC UE creating a conference; 

then the SC UE shall subscribe to the conference event package as specified in 3GPP TS 24.605 [31] and shall populate 
the Contact header field of the SUBSCRIBE request with the g.3gpp. mid-call media feature tag. 

If the subscription is accepted then the SC UE shall keep one subscription to the conference event package with own 
Contact header field containing the g.3gpp.mid-call media feature tag for each conference where the SC UE participates 
using procedures specified in 3GPP TS 24.605 [31]. 

7.3 SCC AS 

7.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 
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SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
the UE. 

The SCC AS shall store the SIP INVITE requests due to static STN (as defined in subclause 9.3.1) and the SIP INVITE 
requests due to originating filter criteria, at least until their sessions are terminated. 

The SCC AS needs to distinguish between the following initial requests to provide specific functionality related to 
obtaining conference participants: 

SIP SUBSCRIBE requests with an Event header field containing "conference" and with the Contact header field 
containing the g.3gpp. mid-call media feature tag routed to the SCC AS over the ISC interface as a result of 
processing initial filter criteria at the S-CSCF according to the originating procedures as specified in 
3GPP TS 24.229 [2]. In the procedures below, such requests are known as "SIP SUBSCRIBE requests to 
conference event package". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4]. 

Ifi 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to originating filter criteria; and 

3. the SCC AS is aware: 

by local policy; or 

by ATCF indicating support of the MSC server assisted mid-call feature; 

NOTE 1 : An ATCF can indicate support of the MSC server assisted mid-call feature by inclusion of the 

g.3gpp. mid-call feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature- 
capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC 
procedures support the MSC Server assisted mid-call feature; 

NOTE 2: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.3gpp. mid-call feature-capability indicator, as described in annex C, in the Feature- 
Caps header field of the SIP 2xx response to the SIP INVITE request due to originating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 

If: 

1 . the SCC AS supports PS to CS SRVCC for calls in alerting phase according to operator policy; 

2. the g.3gpp.srvcc-alerting media feature tag as described in annex C is included in the Contact header field of the 
SIP INVITE request due to originating filter criteria; and 

3. the SCC AS is aware: 
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by local policy; or 

- by ATCF indicating support of the SRVCC for calls in alerting phase; 

NOTE 3: An ATCF can indicate support of the SRVCC for calls in alerting phase by inclusion of the g.3gpp.srvcc- 
alerting feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature- 
capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC servers in the network where the UE is registered which can be involved in PS to CS SRVCC 
procedures support the PS to CS SRVCC for calls in alerting phase; 

NOTE 4: The SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id 
header field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in the 
Feature-Caps header field of any SIP Ixx or 2xx response to the SIP INVITE request due to originating filter criteria as 
described in IETF RFC 6809 [60]. 

If the SCC AS supports the PS to CS SRVCC for calls in alerting phase according to operator policy, the SCC AS shall 
remove the g.3gpp.srvcc-alerting media feature tag as described in annex C from the SIP INVITE request due to 
originating filter criteria before forwarding the SIP INVITE request towards the remote UE. 

The SCC AS shall include the "tdialog" option tag and the "replaces" option tag in the Supported header field of any 
SIP Ixx or 2xx response to the SIP INVITE request due to originating filter criteria. 

7.3.3 Subscription related procedures in tine SCC AS 

When the SCC AS receives a SIP SUBSCRIBE request to conference event package, if the SCC AS supports the MSC 
Server assisted mid-call feature according to operator policy and if SCC AS determines that the subscription is related 
to an anchored session then the SCC AS shall ensure that it remains on the path for future requests in the dialog before 
forwarding the request. 

NOTE: ASs acting as Routeing B2BUA and record-routing ASs acting as SIP proxy remain on the path for future 
requests in the dialog. 

When the SCC AS receives SIP 2xx response to the SIP NOTIFY request with conference information, the SCC AS 
shall update the stored conference information based on the SIP NOTIFY request content and forward the SIP 2xx 
response in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall determine that a subscription to conference event package is related to a session if: 

1 . the session was originated by served SC UE; 

2. remote UE of the session is a conference focus; 

3. the P-Asserted-Identity header field of the served SC UE used at the establishment of the session is the same as 
the P-Asserted-Identity header field of the served SC UE used at the subscription; and 

4. the Contact or the P-Asserted-Identity header field provided to the served SC UE at the establishment of the 
session is the same as the Request-URI used at the subscription; 

If multiple such subscriptions exist, the SCC AS shall select the subscription that originates from the same device as the 
session. 

7.4 EATF 

7.4.1 Distinction of requests sent to tine EATF 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to call origination: 
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SIP INVITE request including a request URI that contains an emergency service URN, i.e. a service URN with a 
top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are 
known as "SIP INVITE requests due to emergency service URN". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

7.4.2 Call origination procedures at the EATF 

When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE 
request until the session is terminated, anchor the session and act as specified for a routeing B2BUA in 
3GPP TS 24.229 [2], subclause 5.7.5.2.1. 

7.5 Access Transfer Control Function (ATCF) 

7.5.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

1) SIP INVITE requests: 

A) with the ATCF URI for originating requests in the topmost Route header field; and 

B) with the Request-URI containing a URI not matching the STI-rSR allocated to the ATCF. 
NOTE: If ATCF does not support the CS to PS SRVCC, the STI-rSR is not allocated to the ATCF. 

In the procedures below, such requests are known as "originating SIP INVITE requests from SC UE". 

2) SIP requests other than SIP INVITE requests creating a dialog, with the ATCF URI for originating requests in 
the topmost Route header field. In the procedures below, such requests are known as "originating SIP requests 
other than INVITE, creating a dialog". 

3) SIP requests for a standalone transaction with the ATCF URI for originating requests in the topmost Route 
header field. In the procedures below, such requests are known as "originating SIP standalone request". 

4) SIP request for an unknown method that does not relate to an existing dialog with the ATCF URI for originating 
requests in the topmost Route header field. In the procedures below, such requests are known as "originating 
unknown SIP requests". 

5) SIP INVITE requests: 

A) with the ATCF management URI in the topmost Route header field; and 

B) with application/vnd.3gpp.srvcc-extH-xml MIME body containing <srvcc-ext> root element containing 
<Setup-info> element containing <direction> element with value "initiator". 

In the procedures below, such requests are known as "originating SIP INVITE requests from MSC server". 

7.5.2 Call origination procedures in the ATCF 
7.5.2.1 General 

For all SIP transactions identified: 

if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised 
Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained 
an authorised Resource-Priority header field; 

the ATCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or 
dialogs. 
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NOTE: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact 
meaning of priority is not defined further in this document, but is left to national regulation and network 
configuration. 

7.5.2.2 Sessions originated in PS domain 

Upon receiving the originating SIP INVITE request from SC UE, the ATCF shall: 

NOTE 1 : Since the ATCF acts as proxy, the dialog identifier of the SIP INVITE request is not modified by 
procedures of the subclause. 

0) insert a Record-Route header field containing the SIP URI of the ATCF; and 

1) if the latest SRVCC-related information received for the registration path which the session being established, 
contains ATU-STI for PS to CS SRVCC and C-MSISDN: 

A) associate the session being estabhshed with the C-MSISDN and the ATU-STI for PS to CS SRVCC bound to 
the registration path (see subclause 6A.3.1); and 

B) if the originating SIP INVITE request from SC UE contains an SDP offer and if the ATCF decided to anchor 
the media according to operator policy as specified in 3GPP TS 23.237 [9], replace the SDP offer in the 
originating SIP INVITE request from SC UE with an updated SDP offer using media parameters provided by 
the ATGW; and 

NOTE 2: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

2) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the 
visited network towards the home network, select an IBCF in the visited network and add the URI of the selected 
IBCF to the topmost Route header field; 

before forwarding the request. 

When the ATCF receives any Ixx or 2xx response to the originating SIP INVITE request from SC UE, the ATCF shall: 

1) save the Contact header field included in the Ixx or 2xx response. 

NOTE 3: If the ATCF subsequently receives an initial INVITE request due to STN-SR, the ATCF will include the 
saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial INVITE 
request due to STN-SR as describe in subclause 12.7.2.2. 

7.5.2.3 Sessions originated in CS domain 

If the ATCF supports the CS to PS SRVCC, upon receiving the originating SIP INVITE request from MSC server, the 
ATCF shall act as B2BUA and shall: 

1) if ATCF contains an SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the <C- 
MSISDN> element of the <Setup-info> element of the value <srvcc-ext> root element of the 
application/vnd.3gpp.srvcc-extH-xml MIME body of the SIP INVITE request: 

A) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) 
containing C-MSISDN equal to the <C-MSISDN> element of the <Setup-info> element of the value <srvcc- 
ext> root element of the application/vnd.3gpp.srvcc-extH-xml MIME body of the SIP INVITE request; and 

B) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request; and 

2) send a SIP INVITE request towards the home network according to 3GPP TS 24.229 [2]. The ATCF shall 
populate the SIP INVITE request towards the home network with: 

A) the Request-URI set to the Request-URI of the originating SIP INVITE request from MSC server; 

B) all Route header fields of the originating SIP INVITE request from MSC server except the topmost Route 
header field; 

C) the Record-Route header field containing the SIP URI of the ATCF; 
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D) the Recv-Info header fields of the originating SIP INVITE request fi-om MSC server except the Recv-Info 
header field containing the g.3gpp. access-transfer-events info package name; 

E) the Accept header fields of the originating SIP INVITE request from MSC server except the Accept header 
field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type; 

F) if an Accept header field of the originating SIP INVITE request from MSC server contains the 
application/vnd.3gpp.access-transfer-eventsH-xml with the "et" parameter indicating ability to receive "event- 
type" attribute with values additional to the value "2": 

a) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and 

b) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; 

G) if the originating SIP INVITE request from MSC server contains an SDP offer and if the ATCF decided to 
anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

a) all MIME bodies of the originating SIP INVITE request from MSC server apart from the 
application/vnd.3gpp.srvcc-extH-xml MIME body and apart from application/sdp MIME body; and 

b) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 

NOTE: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

H) if the originating SIP INVITE request from MSC server does not contain an SDP offer or if the ATCF 
decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

a) all MIME bodies of the originating SIP INVITE request from MSC server apart from the 
application/vnd.3gpp.srvcc-extH-xml MIME body; and 

I) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, select an IBCF in the visited network and add the URJ of the 
selected IBCF to the topmost Route header field. 

When the ATCF receives any SIP Ixx or 2xx response to the SIP INVITE request towards the home network, the 
ATCF shall: 

1) save the Contact header field included in the SIP response; and 

2) generate and send a SIP response to the originating SIP INVITE request from MSC server populated with: 

A) the same status code as the received SIP response to the SIP INVITE request towards the home network; 

B) the Record-Route header field containing the SIP URI of the ATCF; 

C) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the 
g.3gpp. access-transfer-events info package name; 

D) if the SIP response is SIP Ixx response: 

a) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" 
parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and 
values, if any, indicated in the "et" parameter of the g.3gpp. access-transfer-events info package name of 
the Recv-Info header field of the received SIP response; and 

E) if the SIP response is SIP 2xx response: 

a) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; 

b) the Accept header fields of the received SIP response except the Accept header field containing the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME type; and 

c) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and 
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values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-events+xml 
MIME type of the Accept header field of the received SIP response. 

7.5.3 Procedures in the ATCF for originating requests not related to a call 

Upon receiving a 

1 . originating SIP request other than INVITE, creating a dialog; 

2. originating SIP standalone request; or 

3. originating unknown SIP request; 

the ATCF shall: 

1) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the 
visited network towards the home network, select an IBCF in the visited network and add the URI of the selected 
IBCF to the topmost Route header field; 

before forwarding the request. 

7.6 MSC server 

7.6.1 Call origination procedures 

Upon receipt of a CC SETUP message from the SC UE and if the MSC server: 

1) is enhanced for ICS and supports CS to PS SRVCC; and 

2) the latest SRVCC information received for the registration path of the SC UE contains the ATCF management 
URI and the C-MSISDN; 

then when sending the SIP INVITE request due to receipt of a CC SETUP message from the SC UE as specified in 
3GPP TS 29.292 [18] and 3GPP TS 24.292 [4], then the MSC server shall additionally populate the SIP INVITE 
request with: 

1) topmost Route header field with the ATCF management URI and Ir URI parameter; 

2) the Accept header field containing application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" 
parameter indicating ability to receive "event-type" attribute with the value "2"; 

3) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name; 

4) application/vnd.3gpp.srvcc-ext+xml MIME body with the <srvcc-ext> root element containing the <Setup-info> 
element containing the CS to PS SRVCC information bound to the registration path (see subclause 6 A. 3.1) and 
indicating the "initiator" role of the MSC server in the session set up; and 

5) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field. 



8 Roles for call termination for service continuity 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS 
and the ATCF. 
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8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2] with the following clarifications: 

1) If the SC UE supports the MSC server assisted mid-call feature, and the receiving SIP INVITE request includes 
g.3gpp. mid-call feature-capability indicator, as described in annex C, in the Feature-Caps header field, the SC 
UE shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the 
SIP 2xx response to the SIP INVITE request. 

la) If the SC UE supports single radio PS to CS access transfer for calls in alerting state, and the receiving SIP 
INVITE request includes the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in a 
Feature-Caps header field as described in IETF RFC 6809 [60], the SC UE shall include the g.3gpp.srvcc- 
alerting media feature tag as described in annex C in the Contact header field of the SIP 180 (Ringing) response 
to the SIP INVITE request. 

2) If the SC UE not supporting ICS or supporting ICS but with ICS capabilities disabled receives a SIP INVITE 
request containing a SDP offer which includes speech media component transported using an IP bearer, and: 

NOTE 1: An indication that an SC UE with ICS capabilities has its ICS capabilities enabled or disabled can be 
found in the ICS MO ICS_CapabiHties_Enabled leaf node (see 3GPP TS 24.286 [23]). 

a) if the SC UE sends the response to the SIP INVITE request over GERAN; 

b) if the SC UE sends the response to the SIP INVITE request over E-UTRAN or UTRAN, and the IMS VoPS 
indicator indicates that voice is not supported; or 

c) if the SC UE sends the response to the SIP INVITE request over an access network other than E-UTRAN, 
UTRAN and GERAN, and the access network does not support the offered speech media component 
transported using an IP bearer; 

then the SC UE shall send back a SIP 488 (Not Acceptable Here) response without a message body 

The SC UE not supporting ICS or with ICS capabilities disabled shall support termination of calls in the CS domain as 
specified in 3GPP TS 24.008 [8]. 

An SC UE that supports ICS and has ICS capabilities enabled shall follow the call termination procedures as specified 
in3GPPTS24.292[4]. 

When the SC UE not supporting ICS or with ICS capabilities disabled, and supports multiple registrations receives a 
SIP INVITE request containing SDP for establishing a session using just an IP bearer, then the SC UE shall establish 
this session in accordance with 3GPP TS 24.229 [2] with the following clarification: 

if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to 
an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS, the SC UE 
shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog identified by 
the dialog parameters contained in the Target-Dialog header field; and 

if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a 
dialog in the process of being established) between the SC UE and SCC AS, the SC UE shall check if the dialog 
parameters for this request correspond to the dialog parameters received in a Target-Dialog header field received 
on an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS and if so 
then the SC UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog 
that the Target-Dialog header field was received on. 

NOTE 2: The second case is to cover the possibility that requests can arrive out of the order that they were sent. 

8.3 SCC AS 

8.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 
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SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header field. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

2. the SCC AS is aware: 

by local policy; or 

by ATCF indicating support of the MSC server assisted mid-call feature; 

NOTE 1 : An ATCF can indicate support of the MSC server assisted mid-call feature by inclusion of the 

g.3gpp. mid-call feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature- 
capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC 
procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call feature-capability indicator, as described in annex C, in the Feature- 
Caps header field of the SIP INVITE request due to terminating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE. 

If: 

1 . the SCC AS supports PS to CS SRVCC for calls in alerting phase according to operator policy; and 

2. the SCC AS is aware: 

by local policy; or 

by ATCF indicating support of the SRVCC for calls in alerting phase; 

NOTE 2: An ATCF can indicate support of the SRVCC for calls in alerting phase by inclusion of the g.3gpp.srvcc- 
alerting feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature- 
capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC 
procedures support SRVCC for calls in alerting phase; 

then the SCC AS shall include the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in the 
Feature-Caps header field of the SIP INVITE request due to terminating filter criteria as described in 
IETF RFC 6809 [60]. 

If the SCC AS supports PS to CS SRVCC for calls in alerting phase according to operator policy, the SCC AS shall 
remove the g.3gpp.srvcc-alerting media feature tag as described in annex C from SIP Ixx and 2xx responses to the SIP 
INVITE request due to terminating filter criteria before forwarding the SIP Ixx and 2xx responses towards the remote 
UE. 
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The sec AS shall include the "tdialog" option tag and the "replaces" option tag in the Supported header field of the SIP 
INVITE request due to terminating filter sent toward the SC UE. 

8.4 Access Transfer Control Function (ATCF) 

8.4.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

1) SIP INVITE requests with the ATCF URI for terminating requests in the topmost Route header field. In the 
procedures below, such requests are known as "terminating SIP INVITE requests for PS". 

2) SIP INVITE requests: 

A) with the ATCF management URI in the topmost Route header field; and 

B) with application/vnd.3gpp.srvcc-ext+xml MIME body containing <srvcc-ext> root element containing 
<Setup-info> element containing <direction> element with value "receiver". 

In the procedures below, such requests are known as "terminating SIP INVITE requests for CS". 

8.4.2 Call termination procedures in the ATCF 

8.4.2.1 General 

For all SIP transactions identified: 

if priority is supported, as containing an authorised Resource-Priority header field or, if such an option is 
supported, relating to a dialog which previously contained an authorised Resource-Priority header field; 

the ATCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or 
dialogs. 

NOTE: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact 
meaning of priority is not defined further in this document, but is left to national regulation and network 
configuration. 

8.4.2.2 Sessions terminated in PS domain 

Upon receiving the terminating SIP INVITE request for PS, the ATCF shall: 

NOTE 1 : Since the ATCF acts as proxy, the dialog identifier of the SIP INVITE request is not modified by 
procedures of the subclause. 

1) if a Feature-Caps header field containing the g.3gpp.srvcc feature-capability indicator is contained in the SIP 
INVITE request: 

A) insert a Record-Route header field containing the SIP URI of the ATCF; and 

B) if the latest SRVCC-related information received for the registration path which the session being 
established, is using contains ATU-STI for PS to CS SRVCC and C-MSISDN: 

a) associate the session being established with the C-MSISDN and the ATU-STI for PS to CS SRVCC 
bound to the registration path (see subclause 6A.3.1); and 

b) if the terminating SIP INVITE request for PS contains an SDP offer and if the ATCF decided to anchor 
the media according to operator policy as specified in 3GPP TS 23.237 [9], replace the SDP offer in the 
originating SIP INVITE request with an updated SDP offer using media parameters provided by ATGW; 
and 

2) save the Contact header field included in the terminating SIP INVITE request for PS; 
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NOTE 2: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

NOTE 3: If the ATCF subsequently receives an initial INVITE request due to STN-SR, the ATCF will include the 
saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial INVITE 
request due to STN-SR as describe in subclause 12.7.2.2. 

before forwarding the request. 

8.4.2.3 Sessions terminated in CS domain 

If ATCF supports CS to PS SRVCC then upon receiving the terminating SIP INVITE request for CS, the ATCF shall 
act as B2BUA and shall: 

1) save the Contact header field included in the terminating SIP INVITE request for CS; 

2) if ATCF contains an SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the <C- 
MSISDN> element of the <Setup-info> element of the value <srvcc-ext> root element of the 
application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP INVITE request: 

A) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) 
containing C-MSISDN equal to the <C-MSISDN> element of the <Setup-info> element of the value <srvcc- 
ext> root element of the application/vnd.3gpp.srvcc-extH-xml MIME body of the SIP INVITE request; and 

3) send a SIP INVITE request towards the MSC server according to 3GPP TS 24.229 [2]. The ATCF shall populate 
the SIP INVITE request towards the MSC server with: 

A) the Request-URI set to the Request-URI of the terminating SIP INVITE request for CS; 

B) all Route header fields of the terminating SIP INVITE request for CS except the topmost Route header field; 

C) the Record-Route header field containing the SIP URI of the ATCF; 

D) the Accept header fields of the terminating SIP INVITE request for CS except the Accept header field 
containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type; 

E) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with the 
"et" parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and 
values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-eventsH-xml MIME 
type of the Accept header field of the terminating SIP INVITE request for CS. 

F) the Recv-Info header fields of the terminating SIP INVITE request for CS; 

G) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name, if not included 
already; 

H) if the terminating SIP INVITE request for CS contains an SDP offer and if the ATCF decided to anchor the 
media according to operator pohcy as specified in 3GPP TS 23.237 [9]: 

a) all MIME bodies of the terminating SIP INVITE request for CS apart from the 
application/vnd.3gpp.srvcc-extH-xml MIME body and apart from application/sdp MIME body; and 

b) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 
and 

NOTE: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

I) if the terminating SIP INVITE request for CS does not contain an SDP offer or if the ATCF decided not to 
anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

a) all MIME bodies of the terminating SIP INVITE request for CS apart from the 
application/vnd.3gpp.srvcc-extH-xml MIME body. 

When the ATCF receives any SIP Ixx or 2xx response to the SIP INVITE request towards the MSC server, the ATCF 
shall: 
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1) store the value of the g.3gpp.ti media feature tag of the Contact header field of the received SIP response to the 
SIP INVITE request towards the MSC server; and 

2) generate and send a SIP response to the terminating SIP INVITE request for CS populated with: 

A) the same status code as the received SIP response to the SIP INVITE request towards the MSC server; and 

B) the Record-Route header field containing the SIP URI of the ATCF; 

C) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the 
g.3gpp.access-transfer-events info package name; 

D) if the SIP response is SIP Ixx response: 

a) if the SIP response contains an Recv-Info header field containing the g.3gpp. access-transfer-events info 
package name with the "et" parameter indicating ability to receive "event-type" attribute with values 
additional to the value "2", then the Recv-Info header field containing the g.3gpp. access-transfer-events 
info package name with the "et" parameter indicating ability to receive "event-type" attribute with the 
additional values; and 

E) if the SIP response is SIP 2xx response: 

a) if the SIP response contains an Accept header field containing the application/vnd.3gpp.access-transfer- 
eventsH-xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with 
values additional to the value "2": 

i) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type 
with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; 
and 

ii) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name. 

8.5 MSC server 

8.5.1 Distinction of requests 

The MSC server needs to distinguish the following initial SIP requests: 

1) SIP INVITE requests with the topmost Route header field containing the Path header field value inserted by the 
MSC server in a REGISTER request. In the procedures below, such requests are known as "terminating SIP 
INVITE requests from home network". 

2) SIP INVITE requests with the MSC URI for redirected terminating sessions in the topmost Route header field. 
In the procedures below, such requests are known as "redirected terminating SIP INVITE requests". 

8.5.2 Call termination procedures 
8.5.2.1 INVITE from home network 

Upon receiving the terminating SIP INVITE request from home network and if the MSC server: 

1) is enhanced for ICS and supports CS to PS SRVCC; and 

2) the latest SRVCC information received for the registration path of the SC UE contains the ATCF management 
URI and the C-MSISDN; 

then the MSC server instead of interworking of mobile terminating call setup from SIP to NAS signalling according 
3GPP TS 29.292 [18] and 3GPP TS 24.292 [4], the MSC server shall: 

1) send a SIP INVITE request towards the ATCF according to 3GPP TS 24.229 [2]. The MSC server shall populate 
the SIP INVITE request towards the ATCF with: 

A) the Request-URI set to the Request-URI of the terminating SIP INVITE request from home network; 
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B) topmost Route header field with the ATCF management URI and Ir URI parameter; 

C) all MIME bodies of the terminating SIP INVITE request fi^om home network; and 

D) application/vnd.3gpp.srvcc-ext+xml MIME body with the <srvcc-ext> root element containing the <Setup- 
info> element containing the CS to PS SRVCC information bound to the registration path (see 
subclause 6A.3.1) and indicating the "receiver" role of the MSC server in the session set up. 

When the MSC server receives any SIP Ixx or 2xx response to the SIP INVITE request towards the ATCF, the MSC 
server shall generate and send a SIP response to the terminating SIP INVITE requests from home network populated 
with the same status code as the received SIP response to the SIP INVITE request towards the ATCF. 

8.5.2.2 INVITE from ATCF 

If the MSC server is enhanced for ICS and supports CS to PS SRVCC then upon receiving the redirected terminating 
SIP INVITE request, the MSC server shall interworking the mobile terminating call setup from SIP to NAS signalling 
according 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4]. 

When sending a SIP Ixx or 2xx response to the redirected terminating SIP INVITE requests, MSC server shall 
additionally populate the SIP response with: 

1) the g.3gpp.ics media feature tag with value "server" in the Contact header field; 

2) if the SIP response is SIP Ixx response: 

A) Recv-Info header field containing the g.3gpp. access-transfer-events info package name and with the "et" 
parameter indicating ability to receive "event-type" attribute with value "2"; 

3) if the SIP response is SIP 2xx response: 

A) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; and 

B) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with the 
"et" parameter indicating ability to receive "event-type" attribute with the value "2"; and 

4) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field. 



9 Roles for PS-CS access transfer 

9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 

one full-duplex session with active speech or speech/video component; and 

up to one full-duplex session with active speech or speech/video media component and up to one fall-duplex 
session with inactive speech or speech/video media component when the MSC Server assisted mid-call feature is 
supported. 

9.1 A Additional procedures with MSC Server assisted mid-call 
feature 

When a conference is transferred to CS domain using MSC Server assisted mid-call feature, the participants are 
extracted from the stored conference information as follows: 

1. at maximum first 5 participants listed in the <user> elements: 

a. included in <users> parent element included in <conference-info> root element of the conference 
information; 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 48 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

b. containing at least one <endpoint> child element with <status> child element containing one of the states 
"connected", "on-hold", "muted-via-focus", "pending", "alerting", "dialing-in" or "dialing-out"; and 

c where "entity" attribute is different than the URI in the P-Asserted-Identity header field of the served SC UE 
used at the subscription. 

9.2 SC UE 

9.2.0 General 

Void 

9.2.1 SC UE not using ICS procedures for PS to CS access transfer 

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as 
specified in subclause 9.2. 1 A, subject to the SC_non_transferrable_media node value in the Communication Continuity 
MO (see subclause 5.27 in 3GPP TS 24.216 [5]), the SC UE shall: 

a) if more than one full-duplex session with speech media component exists, first initiate the release of all the 
ongoing full-duplex sessions with speech media component except the full-duplex session with active speech 
media component that was most recently made active and then the SC UE shall transfer the remaining ongoing 
full-duplex session with active speech media component. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a CC SETUP message (as specified in 
3GPP TS 24.008 [8]) to the SCC AS to set up a call over the CS domain. When sending CC SETUP message, the SC 
UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the static STN; and 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164". in the Called Party BCD 
Number information element. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS access transfer has not completed 
successfully and the call will continue in the Source Access Leg. 

After completion of session transfer, if the SC UE is not using Gm, the SC UE shall locally release the resources, if any, 
that are associated with the source access leg. 

9.2.1 AA SC UE using ICS procedures for PS to CS access transfer 

If SC UE uses ICS capabilities, this subclause applies for IMS sessions containing speech media component only, 
otherwise subclause II. 2. 1. 2 applies. 

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

If SC using ICS is enabled and if the SC UE is using Gm, then for each session with speech media component to be 
transferred and starting with the session with the active speech media component, the SC UE shall send a SIP INVITE 
request to the SCC AS. The SC UE shall populate the SIP INVITE request as follows: 

1) the Request-URI set to: 

- if the PS to PS STI URI is configureed in the SC UE, the configured PS to PS STI URI; and 

- if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field 
returned at the creation of the dialog on the Source Access Leg; 
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2) include in the Contact header field: 

- a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3) select one of the following options: 

if usage of SIP Replaces extension is selected: 

a) the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b) the Require header field populated with the option tag value "replaces"; 
if usage of SIP Target-Dialog extension is selected: 

a) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b) the Require header field populated with the option tag value "tdialog"; 

4) SDP proposing an audio stream over a circuit-switched bearer in accordance with procedures for SDP for ICS 
UE proposing using a CS audio stream in 3GPP TS 24.292 [4]; and 

5) an indication that the related local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11].- 

Upon the SC UE receiving a reliable SIP Ixx provisional response including a PSI DN from the SCC AS, the SC UE 
shall follow the procedures for ICS YE setting up a CS call in 3GPP TS 24.292 [4]. 

When the CS resources are available to the UE, the SC UE shall send an SDP offer including an indication that the 
related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11]. 

Upon receiving a SIP 2xx response for the SIP INVITE request, the SC UE shall: 

1) send a SIP ACK request; 

2) send a SIP BYE request to the SCC AS on the Source Access Leg to terminate the dialog on the Source Access 
Leg, if the dialog is still active (e.g. it has not been released by the SCC AS) and no active media streams remain 
on that dialog on the Source Access Leg. 

NOTE 1: If the contact address used by the dialog over the Source Access Leg was registered using multiple 

registration procedure, then upon transferring the dialog to the CS domain, the SC UE is still registered on 
the Source Access Leg and its subscription dialog to its reg-event on the Source Access Leg is intact. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then PS-CS access transfer has not 
completed successfully and the call will continue on the PS Access Leg. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS access transfer has not completed 
successfully and the call will continue in the Source Access Leg. 

9.2.1 A SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS 
capabilities if: 

1. the SC UE supports the MSC Server assisted mid-call feature; and 

2. one of the following is true: 

A. there is at least one ongoing full-duplex session with active speech media component and the Feature-Caps 
header field received during the establishment of the ongoing full-duplex session with active speech media 
component which has been most recently made active includes the g.3gpp. mid-call feature-capability 
indicator as described in annex C; or 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 50 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

B. there is no ongoing fall-duplex session with active speech media component and the Feature-Caps header 
field received during the establishment of the ongoing full-duplex session with inactive speech media 
component which became inactive most recently includes the g.3gpp. mid-call feature-capability indicator as 
described in annex C. 

When the SC UE applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.2.1, and before sending a message to set up a call over the CS domain, the SC UE shall: 

1. if there are two or more ongoing full-duplex sessions with active speech media component: 

A. initiate the release of all the ongoing full-duplex sessions with speech media component except two that were 
most recently made active; 

B. initiate the session modification of the ongoing full-duplex session with speech media component that was 
made active less recently and offer the speech media component with "sendonly" or "inactive" directionality; 
and 

C. transfer two remaining ongoing full-duplex sessions with speech media component; 

NOTE 1: When full-duplex session with active speech media component and another session with inactive speech 
media component exist, one CC SETUP message transfers both sessions. 

2. if there are one ongoing full-duplex session with active speech media component and one or more ongoing full- 
duplex session with inactive speech media component: 

A. initiate the release of all the ongoing full-duplex sessions with inactive speech media component except the 
one which became inactive most recently; and 

B. transfer two remaining ongoing full-duplex sessions with speech media component; 

NOTE 2: When full-duplex session with active speech media component and another session with inactive speech 
media component exist, one CC SETUP message transfers both sessions. 

3. if there is one ongoing full-duplex session with active speech media component and no ongoing full-duplex 
session with inactive speech media component, transfer the ongoing full-duplex session with the speech media 
component; and 

4. if there is no ongoing full-duplex session with active speech media component and there is one or more ongoing 
full-duplex session with inactive speech media component: 

A. initiate the release of all the ongoing full-duplex sessions with inactive speech media component except the 
one which became inactive most recently; and 

C. transfer the ongoing full-duplex session with speech media component. 

NOTE 3: The ongoing full-duplex session with inactive speech media component is transferred to a held CS call. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier calculated as in the 
table 9.2.1A-1 and TI flag value as in mobile originated call. 

Table 9.2.1 A-1 : held session transaction identifier calculation formula 



<transaction identifier of the additional transferred session> = {1 + <transaction identifier 
of the CS call established by the SETUP message>) modulo 7 



If: 



1. the SC UE has a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active 
speech media component; or 

2. the ongoing full-duplex session with active speech media component does not exist and the SC UE has a 
subscription as described in subclause 7.2.2 for the ongoing full-duplex session with inactive speech media 
component; 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 51 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order 
in the list of the extracted participants. 

Table 9.2.1 A-2: transaction identifier assignment for participants 



<transaction identifier of participant> = {<transaction identifier of the conference> 
<offset of participant>) modulo 7 



If 

1 . the ongoing full-duplex session with active speech media component exists and the SC UE does not have a 
subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active speech media 
component; and 

2. the SC UE has a subscription as described in subclause 7.2.2 for the additional transferred session; 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the additional transferred session. The offsets 0, 1, 2, 3, 4 are assigned to the 
participants in their order in the list of the extracted participants. 

9.2.1 B SC UE procedures for PS to CS access transfer with MSC server 

assisted mid-call feature for speech and video session 

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in 
the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in 
subclause 9. 2.1 A with the following additions: 

if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive 
the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the 
support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer 
capability preferred for the current active session; and 

if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, 
the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF 
in the CC SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the 
current active session. 

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the 

UE can switch between the two sessions by holding/releasing the active session and resuming the inactive 
session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call 
modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of 
the two sessions from speech to multimedia, or vice versa. 

9.2.2 SC UE procedures for CS to PS access transfer 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CS call setup procedure is complete, e.g. a CC CONNECT message has been sent or 
received as described in 3GPP TS 24.008 [8] or a call for which the SIP 2xx response for the initial SIP INVITE request 
to establish this session has been sent or received. 

If not already registered in the IM CN subsystem, the SC UE shall follow the procedures specified in subclause 6.2 to 
perform registration over the Target Access Leg before performing CS to PS access transfer. 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session with speech media component to be transferred and starting with the one 
with active speech media component, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with 
the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for 
PS-PS access transfer with full media transfer in subclause 10.2.1. 
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If the original sessions are not established using ICS capabilities and the SC UE does not support the MSC Server 
assisted mid-call feature as described in subclause 9.2.3, subject to the SC_non_transferrable_media node value in the 
Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]) the SC UE shall: 

a) if more than one full-duplex session with speech media component exists, first initiate the release of all the 

ongoing sessions that are currently not active with the UE procedures specified in 3GPP TS 24.083 [43] and then 
the SC UE shall transfer the remaining ongoing full-duplex session with active speech media component. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS 
in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE 
request as follows: 

1) the Request-URI set to the static STI; and 

2) include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2], if a 
GRUU was received at registration. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 

3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 

release the CS bearer. 

After completion of session transfer, if the SC UE is not using Gm, the SC UE shall locally release the resources, if any, 
that are associated with the source access leg. 

9.2.3 SC UE procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request 
for transferring the session not using ICS capabilities as follows in addition to the procedures described in 
subclause 9.2.2: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the g.3gpp. mid-call media feature tag as described in annex C. 

NOTE 1 : If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and 
the SCC AS and the SC UE support the MSC Server assisted mid-call feature, up to one active and up to 
one inactive CS call can be transferred. 

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request for transferring the 
session not using ICS capabilities: 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Target-Dialog URI header field in the URI of the Refer-To header field; 

4. where the g.3gpp. mid-call feature-capability indicator, as specified in annex C, was included in the Feature-Caps 
header field of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D. 1 .3; 

and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for an additional inactive session in accordance with the procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 
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A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field: 

a. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

b. the g.3gpp. mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request. 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

Upon receiving a SIP 2xx response for the SIP INVITE request, then the SC UE shall proceed as specified in 

subclause 7.2.2. 

9.3 sec AS 

9.3.0 General 

Void 

9.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing the Inter UE Transfer SCC AS URI defined in 
3GPP TS 24.337 [64] in the Request-URL In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URL In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 

- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 

described in 3GPP TS 24.292 [4]) in the Request-URL In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in Target-Dialog 
header field and containing additional transferred session SCC AS URI in the Request-URJ. In the procedures below 
such requests are known as "SIP INVITE requests transferring additional session". 

NOTE 1 : The media streams that need to be transferred are identified using information described in the subsequent 
sections. 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 54 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

NOTE 2: SIP INVITE requests routed to the SCC AS containing the additional transferred session SCC AS URI in 
the Request-URI which are used in the PS-CS access transfer with the MSC server assisted mid-call 
feature are handled by the PS-PS access transfer procedure as described in subclause 10.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS access transfer 

This subclause does not apply to reception of a SIP INVITE request due to STI with CS media and other kind of media 
or without CS media. 

When the SCC AS receives a SIP INVITE request due to STI with CS media only on the Target Access Leg, the SCC 
AS shall follow the procedures specified in subclause 10.3.2 with the following exceptions: 

As the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall 
follow the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the 
SC UE and wait for the SC UE to set up CS bearer before sending SIP re-INVITE to the remote end. 

The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing dialog supporting a session based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field or P-Asserted-Identity header field 
or Contact header field, and send a SIP re-INVITE request towards the remote UE using the existing established dialog. 
By an ongoing dialog supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received. 

NOTE 1 : Multiple dialogs supporting a session associated with the same SC UE can have been anchored when the 
SCC AS receives a SIP INVITE request due to static STN. This can occur in the event that the UE does 
not succeed in releasing all dialogs supporting a session with inactive speech media component or if the 
UE applies the MSC Server assisted mid-call feature. 

The identification of the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active speech media component exists for the user identified in the 
P-Asserted-Identity header field and a SIP 2xx response has been sent, then continue the session transfer with the 
dialog supporting a session with active speech media component; 

2. if no dialogs supporting a session with active speech media component exist for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC 
Server assisted mid-call feature as specified in subclause 9.3.2A, then send a SIP 480 (Temporarily Unavailable) 
response to reject the SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session with active speech media component exists for the user identified in 
the P-Asserted-Identity header field for which SIP 2xx responses have been sent, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received SIP 
INVITE request due to static STN. If more than one such dialogs exists from the same device, the SCC AS shall 
proceed with the next step in this list; and 

NOTE 2: Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the correlation MSISDN or the GRUU of the originating 
user as determined via registration procedures as defined in subclause 6.3. 

4. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active speech media component exists and a SIP 2xx response 
has been sent for that dialog, then: 

if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then 
the SCC AS may release the dialogs supporting a session with inactive speech media component and 
continue the session transfer procedures with the dialog supporting a session with active speech media 
component; or 
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if the sec AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

5. if more than one dialog supporting a session with active speech media component exist for the user identified in 
the P-Asserted-Identity header field and a SIP 2xx response has been sent for that dialog, then: 

if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the 
SCC AS may release all dialogs supporting a session with speech media component of the user identified in 
the P-Asserted-Identity header field for which a SIP 2xx response has been sent except the one with the 
active speech media component that was most recently made active and continue the session transfer 
procedures; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) set the contact header field to the contact header field provided by the served UE at the creation of the dialog 
with the remote UE; and 

3) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, then: 

if the source access leg contains only one speech media component the SCC AS shall initiate release of the 
source access leg by sending a SIP BYE request toward the S-CSCF for sending to the served SC UE; or 

NOTE 3: The SC UE will receive this SIP BYE request only if the SC UE is using Gm after the PS-CS access 
transfer is completed 

If the Source Access Leg contains media components other than speech media component, the SCC AS should 
send a SIP re-INVITE request to update the source access leg. 

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STN includes the g.3gpp. mid-call media feature 
tag as specified in annex C; and 

2. one of the following is true: 

A. at least one confirmed dialog supporting a session with active speech media component exists for the user 
identified in the P-Asserted-Identity header field and the following is true for the confirmed dialog 
supporting a session with active speech media component which has been most recently made active: 

the Contact header field provided by the SC UE at the establishment of the dialog supporting a session 
with active speech media component which has been most recently made active included the g.3gpp. mid- 
call media feature tag as described in annex C; and 

- the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog 
included the g.3gpp.mid-call feature-capability indicator as described in annex C; or 

B. no confirmed dialog supporting a session with active speech media component exists for the user identified in 
the P-Asserted-Identity header field, one or more confirmed dialogs supporting a session with inactive speech 
media component exists for the user and the following is true for the confirmed dialog supporting a session 
with inactive speech media component which has been most recently made inactive: 

the Contact header field provided by the SC UE at the establishment of the dialog included the 
g.3gpp.mid-call media feature tag as described in annex C; and 
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the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog 
included the g.3gpp. mid-call feature-capability indicator as described in annex C. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, and before determining that the SCC AS is not able to identify one dialog for session transfer, the SCC 
AS may: 

1. if more than one confirmed dialog supporting a session exists for the user identified in the P-Asserted-Identity 
header field, and exactly one confirmed dialog supporting a session with active speech media component exists 
and there is at least one remaining confirmed dialog supporting a session with inactive speech media component, 
then: 

release all dialogs supporting a session with active speech media component for which SIP 2xx responses 
have not been sent for these dialogs; 

release all confirmed dialogs supporting a session with inactive speech media component except the one with 
the speech media component which became inactive most recently and continue the session transfer 
procedures with the confirmed dialog supporting a session with active speech media component; 

2. if more than one confirmed dialog supporting a session with active speech media component exists for the user 
identified in the P-Asserted-Identity header field, release all confirmed dialogs supporting a session with speech 
media component except two with the speech media component which became active most recently and continue 
the session transfer procedures with the confirmed dialog supporting a session with the speech media component 
which became active most recently; and 

3. if no confirmed dialog supporting a session with active speech media component exists for the user identified in 
the P-Asserted-Identity header field, one or more confirmed dialogs supporting a session with inactive speech 
media component exists for the user then the SCC AS may release all confirmed dialogs supporting a session 
with speech media component except the one with the speech media component which became inactive most 
recently and continue the session transfer procedures with the confirmed dialog supporting a session with 
inactive speech media component. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call feature-capability indicator, as described in annex C, in 
the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to static STN. 

When the SCC AS applies the MSC Server assisted mid-call feature and a confirmed dialog supporting a session with 
inactive speech media component was associated with the SIP INVITE request due to static STN, in addition to the 
procedures described in subclause 9.3.2, the SCC AS shall set the directionality of the audio media in the SDP offer as 
used in the session with remote UE. 

If: 

the SCC AS applies the MSC Server assisted mid-call feature; 

the session associated with the SIP INVITE request due to static STN is related to a subscription as described in 
subclause 7.3.3; and 

a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and 
IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to static STN. The SCC AS shall populate the 
SIP INFO request as follows: 

1 . include the Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp. mid-call package name; 
and 

2. include application/vnd.3gpp.mid-callH-xml XML body associated with the info package according to 
IETF RFC 6086 [54] and containing the participants extracted as specified in the subclause 9.1 A of the 
subscription related to the session associated with the SIP INVITE request due to static STN as described in 

subclause 7.3.3. 

If the SCC AS applies the MSC Server assisted mid-call feature, two confirmed dialogs supporting a session with 
speech media component exist for the user identified in the P-Asserted-Identity header field then the SCC AS shall send 
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a SIP REFER request towards the MSC Server in accordance with the procedures specified in 3GPP TS 24.229 [2], 
IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request due to static STN. The 
sec AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the additional transferred session, i.e. session 
with speech media component other than the session associated with the SIP INVITE request due to static STN, 
i.e. set to the additional transferred session SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and: 

a. if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and 

b. if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

4. the Content-Type header field with the value set to MIME type as specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D. 1 .2. If 

A. the session associated with the SIP INVITE request due to static STN is not related to any subscription as 
described in subclause 7.3.3; 

B. the additional transferred session is related to a subscription as described in subclause 7.3.3; and 

C. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then SCC AS shall populate the XML body with the participants extracted as specified in the subclause 9.1 A of 
the subscription related to the additional transferred session as specified in subclause 7.3.3. 

When the SCC AS receives a SIP INVITE request transferring additional session, the SCC AS shall: 

associate the SIP INVITE request transferring additional session with a previously established SIP dialog i.e. 
identify the Source Access Leg. The SIP dialog on the Source Access Leg is identified by matching the dialog 
ID present in the Target-Dialog header field (see IETF RFC 4538 [1 1]) of the SIP INVITE request transferring 
additional session with the previously established SIP dialog. By a previously established SIP dialog, it is meant 
a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. 

if the SCC AS is unable to associate the SIP INVITE with a unique previously established SIP dialog, send a SIP 
480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, send a 
SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining 
steps; 
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send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], 
containing the following media information: 

a) the media characteristics as received in the SIP INVITE request transferring additional session for media 
streams whose port is not set to zero; and 

b) for the media streams in the SIP INVITE request transferring additional session whose port is set to zero, 
include the corresponding media characteristics of those streams from the Source Access Leg, 

for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; otherwise, 
for a partial media transfer, after receiving the SIP ACK request from the SC UE on the Target Access Leg, upon 
receiving an update (e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, process the update request 
in accordance with 3GPP TS 24.229 [2]. 

9.3.3 SCC AS procedures for CS to PS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg offering PS media only, the 
SCC AS shall follow the procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing dialog supporting a session. By an ongoing dialog supporting a session, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs supporting a 
session associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due 
to static STI. This can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with 
inactive speech media component or if the UE supports the MSC Server assisted mid-call feature, in which case the 
identification of the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active speech media component exists for the user identified in the 
P-Asserted-Identity header field and a 2xx response has been sent, then continue the session transfer procedures; 

2. if no dialogs supporting a session with active speech media component exists for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC 
Server assisted mid-call feature as specified in subclause 9.3.4, then send a SIP 480 (Temporarily Unavailable) 
response to reject the SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active speech media component and a SIP 2xx response has 
been sent for that dialog, then: 

A. if the remaining dialogs support a session with inactive speech media component and the SCC AS does not 
apply the MSC Server assisted mid-call feature as specified in subclause 9.3.4, then the SCC AS may release 
the dialogs supporting a session with inactive speech media component and continue the session transfer 
procedures with the dialog supporting a session with active speech media component; and 

4. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a SIP 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 
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9.3.4 sec AS procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

The sec AS shall apply the MSC Server assisted mid-call feature if: 

1 . the Contact header field of the SIP INVITE request due to static STI includes the g.3gpp. mid-call media feature 
tag as specified in annex C; and 

2. the sec AS supports the MSC Server assisted mid-call feature according to operator policy. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.3, and before determining that the SCC AS is not able to identify one dialog for session transfer, SCC AS 
may: 

1 . if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
dialog supporting a session with active speech media component exists, and a SIP 2xx response has been sent for 
that dialog and there is at least one remaining dialog supporting a session with inactive speech media component, 
release all dialogs supporting a session with inactive speech media component except the one with the speech 
media component which became inactive most recently and continue the session transfer procedures with the 
dialog supporting a session with active speech media component; and 

2. if no dialog supporting a session with active speech media component exists for the user identified in the P- 
Asserted-Identity header field, one or more dialogs supporting a session with inactive speech media component 
exists for the user and a SIP 2xx response has been sent for these dialogs then the SCC AS may release all 
dialogs supporting a session with speech media component except the one with the speech media component 
which became inactive most recently and continue the session transfer procedures with the dialog supporting a 
session with inactive speech media component. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call feature-capability indicator, as described in annex C, in 
the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to static STI. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 
speech media component was associated with the SIP INVITE request due to static STI, in addition to the procedures 
described in subclause 9.3.3, the SCC AS shall set the directionality of the speech media component in the SDP offer as 
used in the session with remote UE. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with a speech 
media component exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been 
sent for those dialogs then the SCC AS shall send a SIP REFER request towards the SC UE in accordance with the 
procedures specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the 
SIP INVITE request due to static STI. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STI, i.e. set to the additional transferred session 
SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the MSC Server; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. if the remote UE did not request privacy then the To URI header field populated as specified in 

IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session 
establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type URI header field with "application/sdp"; and 
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F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and with directionality as used by the MSC Server; 

4. the Content-Type header field with the value set to MIME type specified in the annex D. 1.3; and 

5. a XML body compliant to the XML schema specified in the annex D.1.2. 

When the SCC AS receives a SIP INVITE request transferring additional session, the SCC AS shall: 

associate the SIP INVITE request transferring additional session with a previously established SIP dialog i.e. 
identify the Source Access Leg. The SIP dialog on the Source Access Leg is identified by matching the dialog 
ID present in the Target-Dialog header field (see IETF RFC 4538 [1 1]) of the SIP INVITE request transferring 
additional session with the previously established SIP dialog. By a previously established SIP dialog, it is meant 
a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. 

if the SCC AS is unable to associate the SIP INVITE with a unique previously established SIP dialog, send a SIP 
480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, send a 
SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining 

steps; 

send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], 
containing the following media information: 

a) the media characteristics as received in the SIP INVITE request transferring additional session for media 
streams whose port is not set to zero; and 

b) for the media streams in the SIP INVITE request transferring additional session whose port is set to zero, 
include the corresponding media characteristics of those streams from the Source Access Leg; and 

for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; otherwise, 
for a partial media transfer, after receiving the SIP ACK request from the SC UE on the Target Access Leg, upon 
receiving an update (e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, process the update request 
in accordance with 3GPP TS 24.229 [2]. 

9.4 MSC server enhanced for ICS 

If the MSC server enhanced for ICS has registered for the user, it shall apply the procedures as specified in 
3GPPTS 29.292 [18]. 

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, it shall apply the procedures 
specified in subclause 9.5 and subclause 9.6. 

9.4.1 Void 
9.4.1A Void 

9.5 PS to CS session continuity with IVISC server assisted mid- 
call feature 

This subclause describes the procedures required by an MSC server in order to support the MSC server assisted mid call 
feature. 

The MSC server shall populate the SIP INVITE request as follows: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 
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2. the Accept header field containing the MIME type as specified in annex D. 1 .3; 

3. include in the Contact header field the g.3gpp. mid-call media feature tag as described in annex C; and 

4. the Recv-Info header field containing the g.3gpp. mid-call package name. 

NOTE 1: Since the MSC server is not able to distinguish the dual radio access transfer from the regular session set 
up, the information elements above are added to every SIP INVITE request sent by the MSC server. 

Upon receiving a SIP INFO request with the Info-Package header field containing the g.3gpp. mid-call package name 
and with the application/vnd.3gpp.mid-callH-xml MIME body associated with the info package according to 
IETF RFC 6086 [54], if the SIP INVITE request established a session with conference focus, then the MSC server 
shall associate the participants extracted from the application/vnd.3gpp.mid-callH-xml MIME body with transaction 
identifiers calculated as in the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the 
participants in their order in the list of the extracted participants. 

Upon receiving a SIP REFER request 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside an existing SIP dialog: 

A. which was originated by the MSC server; and 

B. where the g.3gpp. mid-call -capability indicatorfeature as specified in annex C was included in the Feature- 
Caps header field of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D. 1 .3; 
the MSC server shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional inactive session not using ICS capabilities in accordance 
with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. Additionally, the MSC server 
shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request; and 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 
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e. all or subset of payload type numbers and their mapping to codecs and media parameters not conflicting 
with those in the "body" URI header field in the URI in the Refer-To header field of the received SIP 
REFER request. 

If two sessions are transferred, the MSC server shall: 

1. associate the SIP INVITE request for an additional inactive session with CS call with transaction identifier 
calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated call; and; 

2. if the SIP INVITE request for an additional inactive session established a session with conference focus then 
associate the participants extracted from the application/vnd.3gpp.mid-call+xml MIME body included in the SIP 
REFER request with transaction identifiers calculated as in the table 9.2.1A-2 and with TI flag of the session. 
The offsets 0, 1, 2, 3, 4 are assigned to the participants in their order in the list of the extracted participants. 

9.6 PS to CS session continuity with IVISC server assisted mid- 
call feature for speech and video session 

This subclause describes the procedures required by an MSC server in order to support the MSC server assisted mid call 
feature for speech and video session. 

The MSC server , upon receiving the session state information which indicates an inactive speech and video session, 
shall send a SIP INVITE request for the additional inactive speech and video session as described in subclause 9.5. 

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video 

media can not be supported in CS network for the speech and video session, then the MSC server can set 
the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the 
additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio 
media of the speech and video session is transferred to CS. 

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages 
are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release 
the active session and Retrieve message to retrieve the inactive session), the MSC server can perform the 
procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC server can complete the 
in-call modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS 
bearer of the two sessions from speech to multimedia, or vice versa, before sending a SIP UPDATE or 
SIP re-INVITE message to the SCC AS to resume the inactive session. 



1 Roles for PS-PS access transfer 

10.1 Introduction 

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 

10.2 SCUE 
10.2.0 General 

The SC UE may be engaged in one or more ongoing sessions or in one or more SIP dialogs in early state before 
performing access transfer. By an ongoing session, it is meant a session for which the SIP 2xx response for the initial 
SIP INVITE request to establish this session has been sent or received. By a SIP dialog in early state, it is meant an 
early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the 
SIP 2xx response has not yet been sent or received. 

The SC UE shall follow the procedures specified in subclause 6.2 to perform registration in the IM CN subsystem on 
the newly selected access network before performing PS-PS access transfer. When registering a new contact address, 
the SC UE may either: 
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a) not employ the multiple registration mechanism. In this case, upon the registration of the new contact address, all 
dialogs associated with the old contact address are terminated by the S-CSCF. The terminated dialogs include the 
dialog on the Source Access Leg and the SC UE's subscription dialog to its reg-event; or 

NOTE 1: Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified 
in subclause 10.3.4, upon receiving an initial SIP INVITE request due to PS to PS STI (i.e. on the Targer 
Access Leg) containing the Replaces header field, the SCC AS will be able to identify the dialog toward 
the the remote UE associated with the dialog on the Source Access Leg being replaced. 

b) employ the multiple registration mechanism. In this case, the SC UE may either: 

add new flow that terminates at the new contact address, and leave all dialogs associated with the old flow 
and old contact address intact; or 

replace the old flow that terminates at the old contact address with a new flow that terminates at the new 
contact address, resulting in all dialogs associated with the old flow and old contact address being terminated 
(include the dialog on the Source Access Leg and the SC UE's subscription dialog to its reg-event). 

NOTE 2: Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified 
in subclause 10.3.4, upon receiving an initial SIP INVITE request due to PS to PS STI (i.e. on the Targer 
Access Leg) containing the Replaces header field, the SCC AS will be able to identify the dialog toward 
the the remote UE associated with the dialog on the Source Access Leg being replaced. 

NOTE 3: When transferring all media from the Source Access Leg to the Target Access Leg, the SC UE can 
replace the old flow with a new flow, and let the network terminate all dialogs and the registration 
associated with the old flow, rather than the SC UE performing these actions itself. 

10.2.1 Full session transfer 

This subclause specifies a full session transfer applicable to a SC UE that supports dual mode operation and multiple 
registration procedure. 

To initiate PS-PS access transfer for a session, upon acquiring the resources for media on the Target Access Leg, the SC 
UE shall send a SIP INVITE request due to PS to PS STI on the Target Access Leg in accordance with UE procedures 
specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

1) the Request-URI set to 

A) if the PS to PS STI URI is configured in the SC UE, the configured PS to PS STI URI; and 

B) if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field 
returned at the creation of the dialog on the Source Access Leg; 

2) include in the Contact header field: 

A) a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B) the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3) select one of the following options: 

A) if usage of SIP Replaces extension is selected: 

a) the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b) the Require header field populated with the option tag value "replaces"; 

B) if usage of SIP Target-Dialog extension is selected: 

a) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b) the Require header field populated with the option tag value "tdialog"; 
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4) the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added, and such that each media line indicates the 
same media type as its corresponding media component in the original session and contains at least one codec 
that was negotiated during the original session. 

A) If the SC UE determines to remove a media component during the transfer, then the SC UE shall set the 
media line for this media component to a port number with value zero; and 

B) If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP and indicate that the resources are available; and 

5) if the Source Access Leg is an early dialog and this early dialog was created by the SC UE receiving a SIP 
INVITE request, indicate support of the info package mechanism as specified in IETF RFC 6086 [54]. 

NOTE 1: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

If the dialog on the Source Access Leg is a confirmed dialog, then upon receiving SIP 2xx response for its SIP INVITE 
request due to PS to PS STI sent on the Target Access Leg, the SC UE shall: 

1) send a SIP ACK request; 

2) consider the confirmed dialog on the Source Access Leg as being successfully transferred to the Target Access 
Leg; and 

3) send a SIP BYE request to the SCC AS on the Source Access Leg to terminate the confirmed dialog on the 
Source Access Leg, if the confirmed dialog is still active (e.g. it has not been released by the SCC AS). 

NOTE 2: If the dialog on the Source Access Leg is a confirmed dialog, the SC UE upon sending an initial SIP 
INVITE request due to PS to PS STI on the Target Access Leg will not receive any SIP provisional 
response from the SCC AS, i.e. the initial SIP INVITE request due to PS to PS STI is either accepted with 
the SIP 200 (OK) response containing the SDP answer or rejected with an appropriate final SIP response. 

NOTE 2A: If the contact address used by the dialog over the Source Access Leg was registered using multiple 
registration procedure, and the flow over the Target Access Leg did not replace the flow over the Source 
Access Leg, then upon transferring the dialog to the Target Access Leg, the SC UE is still registered on 
the Source Access Leg and its subscription dialog to its reg-event the Source Access Leg is intact. 

If the dialog on the Source Access Leg is a confirmed dialog and if the SC UE receives any SIP 4xx - 6xx response to 
the SIP INVITE request due to PS to PS STI sent on the Target Access Leg, then PS-PS access transfer has not 
completed successfully and the call will continue in the Source Access Leg. 

If the dialog on the Source Access Leg is an early dialog, then upon receiving a SIP 183 (Session Progress) response for 
its SIP INVITE request due to PS to PS STI sent on the Target Access Leg containing the SDP answer, the SC UE 
shall: 

NOTE 3: If the dialog on the Source Access Leg is an early dialog, then the SC UE upon sending an initial SIP 
INVITE request due to PS to PS STI on the Target Access Leg, receives either a SIP 183 (Session 
Progress) response containing the SDP answer or the initial SIP INVITE request due to PS to PS STI is 
rejected with an appropriate final SIP response. 

1) respond with a SIP PRACK request; and 

2) upon receiving the SIP 200 (OK) response for the SIP PRACK request, consider the early dialog on the Source 
Access Leg as being successfully transferred to the Target Access Leg and being at the same early dialog stage 
as the early dialog on the Source Access Leg. 
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NOTE 4: All subsequent SIP requests or SIP responses originating from the remote UE and destined for the SC UE 
will be sent to the SC UE over the Target Access Leg. For example, in case of an early dialog originated 
by the SC UE sending an initial SIP INVITE request to the remote UE and receiving a SIP 183 (Session 
Progress) response on the Source Access Leg, and subsequently transferring the early dialog to the Target 
Access Leg, the SIP 180 (Ringing) response from the remote UE will be conveyed to the SC UE on the 
Target Access Leg rather than on the Source Access Leg. 

Since, upon receiving the SIP 200 (OK) response for the SIP PRACK request, the early dialog and the associated media 
have been transferred from the Source Access Leg to the Target Access Leg (i.e. the resources for media on the Source 
Access Leg are not used any more), the SC UE may releases the resources on the Source Access Leg by sending a SIP 
UPDTE request with an appropriate SDP offer on the Source Access Leg. However, in spite of releasing the resources, 
the dialog on the Source Access Leg is still in the early dialog phase. 

If the dialog on the Source Access Leg is an early dialog that was created by the SC UE receiving a SIP INVITE 
request on the Source Access Leg (i.e. an incoming call), then upon receiving the SIP 200 (OK) response for the SIP 
PRACK request, the SC UE shall: 

1) if the served user accepted the incoming call: 

a) send the SIP INFO request on the Target Access Leg containing: 

A) an Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp.state-and-event info 
package name; and 

B) application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to 
IETF RFC 6086 [54] and with the event XML element containing "call-accepted" to indicate that the 
called party has answered the call; 

b) upon receiving the SIP 200 (OK) response for the SIP INFO request, and subsequently upon receiving a SIP 
200 (OK) response for its SIP INVITE request due to PS to PS STI sent on the Target Access Leg: 

A) consider the early dialog becoming a confirmed dialog and as being successfully transferred to the Target 
Access Leg; and 

B) release the early dialog on the Source Access Leg, by sending a SIP 410 (Gone) response on the Source 
Access Leg, if this early dialog is still active (e.g. it has not been previously terminated by the SCC AS); 

2) if the incoming call is rejected: 

NOTE 5: If, upon the early dialog being transferred to the Target Access Leg, the SC UE rejects the incoming call, 
the SC UE will terminate the early dialog on the Target Access Leg and the early dialog on the Source 
Access Leg. 

a) send a CANCEL request on the Target Access Leg that pertains to the SIP INVITE request due to PS to PS 
STI; and 

b) send a SIP 410 (Gone) response to the initial SIP INVITE request received on the Source Access Leg; or 

3) if the early dialog is transferred back from the Target Access Leg to the Source Access Leg (e.g. the radio is lost 
while the SC UE is ringing) before the SC UE sends the SIP INFO request on the Target Access Leg: 

NOTE 6: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will 
re-acquire the resources for media on the Source Access Leg, terminate the early dialog on the Target 
Access Leg, and accept the incoming call on the Source Access Leg. 

a) release the early dialog on the Target Access Leg, by sending a SIP CANCEL request on the Target Access 
Leg that pertains to the SIP INVITE request due to PS to PS STI; 

b) re-acquire the resources for media on the Source Access Leg, if previously released, send a SIP UPDATE 
request with an appropriate SDP offer on the Source Access Leg; and 

c) when the served user ether accepts the call or the call is rejected, send the respective final SIP response on 
the Source Access Leg, as specified in 3GPP TS 24.229 [2]. 
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If the dialog on the Source Access Leg is an early dialog that was created by the SC UE sending a SIP INVITE request 
on the Source Access Leg (i.e. an outgoing call), then upon receiving SIP 200 (OK) response for the SIP PRACK 
request, the SC UE shall: 

1) if the SC UE receives a SIP 200 (OK) response for the SIP INVITE request due to PS to PS STI sent on the 
Target Access Leg (i.e. the outgoing call is accepted by the remote UE): 

a) send a SIP ACK request to the received SIP 200 (OK) response; 

b) consider the early dialog becoming a confirmed dialog and as being successfully transferred to the Target 
Access Leg; and 

c) terminate the early dialog on the Source Access Leg, by sending a SIP CANCEL request on the Source 
Access Leg, if this early dialog is still active (e.g. has not been previously terminated by the SCC AS); 

2) if the SC UE receives a the SIP 410 (Gone) response to the initial SIP INVITE request on the Source Access 
Leg, and subsequently any SIP 4xx or 5xx final response to the SIP INVITE due to PS to PS STI (i.e. the 
outgoing call is rejected by the remote UE): 

a) consider the early dialogs as terminated; or 

NOTE 7: If the remote UE rejects the call, the SCC AS will terminate the early dialog on the Source Access Leg 
prior to terminating the early dialog on the Target Access Leg. This will insure that the SC UE does not 
un-necessarily transfer the call to the Source Access Leg (e.g. re-acquires the resources for media) prior 
to the early dialog on the Source Access Leg being terminated. 

3) if the early dialog is transferred back from the Target Access Leg to the Source Access Leg (e.g. the radio is lost 
while the remote UE is ringing) before the SC UE receives any final response on the Target Access Leg: 

NOTE 8: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will 
re-acquire the resources for media on the Source Access Leg, terminate the early dialog on the Target 
Access Leg, and wait for the outgoing call to be either accepted or rejected by the remote UE. 

a) release the early dialog on the Target Access Leg, by sending a SIP CANCEL request on the Target Access 
Leg that pertains to the SIP INVITE request due to PS to PS STI; 

b) re-acquire the resources for media on the Source Access Leg, if previously released and send a SIP UPDATE 
request with an appropriate SDP offer on the Source Access Leg; and 

c) wait for the final SIP response from the remote UE on the Source Access Leg that will indicate whether the 
call was accepted or rejected by the remote UE, and proceed as specified in 3GPP TS 24.229 [2]. 

If the dialog on the Source Access Leg is an early dialog and if the SC UE receives a SIP 4xx - 6xx response to its 
initial SIP INVITE request due to PS to PS STI sent on the Target Access Leg, (i.e. the access transfer of the early 
dialog has not completed successfully), the early dialog shall continue on the Source Access Leg, if this early dialog is 
still active. Hence, the SC UE shall: 

NOTE 9: Since the early dialog on the Target Access Leg is terminated by the SCC AS, the SC UE re-acquires the 
resources on the Source Access Leg.. 

a) re-acquire the resources for media on the Source Access Leg, if previously released and send a SIP UPDATE 
request with an appropriate SDP offer on the Source Access Leg; and 

b) respond with a SIP ACK request to the SIP 4xx - 6xx response, and consider the early dialog on the Target 
Access Leg as terminated, and either: 

A) wait for the final SIP response from the remote UE on the Source Access Leg that will indicate whether 
the call was accepted or rejected by the remote UE, if the call is originated by the SC UE; or 

B) send the respective final SIP response on the Source Access Leg when the call is accepted or rejected by 
the user, if the call is terminated at the SC UE. 
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1 0.2. 1 A Additional procedures for full session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.1, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request due to PS to PS STI the 
g.3gpp. mid-call media feature tag as described in annex C. 

1 0.2.2 Partial session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request due to PS to PS STI over the 
Target Access Leg in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the 
SIP INVITE request as follows: 

1 . the Request-URI set to 

A) if the PS to PS STI URI is configured in the SC UE, the configured PS to PS STI URI; and 

B) if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field 
returned at the creation of the dialog over the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. the Require header field with the option tag 'tdialog' included; 

4. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the session to be transferred; and 

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added during the session transfer, and such that each 
media line indicates the same media type as its corresponding media component in the original session and 
contains at least one codec that was negotiated during the original session. 

A. If the SC UE determines to keep the media component on the Source Access Leg, then the SCUE shall set 
the media line for this media component to a port number with value zero; and 

B. If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request due to PS to PS STI sent over the Target Access Leg and 
sending SIP ACK request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to 
update the original session. The SC UE shall populate the SIP re-INVITE request as follows: 

1 . the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall set the port number for a media 
component to zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request due to PS to PS STI sent over the Target 
Access Leg, then PS-PS access transfer has not completed successfully and the call will continue in the Source Access 
Leg. 
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1 0.2.3 Additional procedures for partial session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.2, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request due to PS to PS STI the 
g.3gpp. mid-call media feature tag as described in annex C. 

10.3 sec AS 

1 0.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

if the g.3gpp.pstops-sti media feature tag was included in the Contact header field of the REGISTER request 
when the SC UE registered, SIP INVITE requests routed to the SCC AS with the Request-URI containing the PS 
to PS STI URI belonging to the subscribed user are known as "SIP INVITE requests due to STI". 

if the g.3gpp.pstops-sti media feature tag was not included in the Contact header field of the REGISTER request 
when the SC UE registered, SIP INVITE requests routed to the SCC AS containing a STI belonging to the 
subscribed user in the Replaces header field or Target-Dialog header field and not containing Inter UE Transfer 
SCC AS URI in the Request-URI and not containing the additional transferred session SCC AS URI in the 
Request-URI are known as "SIP INVITE requests due to STI". 

NOTE 1 : The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS access transfer procedures at the SCC AS 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall: 

associate the SIP INVITE request on the Target Access Leg with a confirmed dialog or an early dialog on the 
Source Access Leg by matching the dialog identifier present in either the Replaces header field (see 
IETF RFC 3891 [10]) or the Target Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE request 
with a confirmed dialog or with an early dialog. By a previously established dialog, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. By an early dialog, it is 
meant an early dialog which has been created by a provisional response to the initial SIP INVITE request, but 
for which the SIP 2xx response has not yet been sent or received; 

if the SCC AS is unable to associate the SIP INVITE request with a confirmed dialog or an early dialog, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STI and not processes the 
remaining steps; 

if the SIP INVITE request contains a Replaces header field: 

a) void; and 

b) send a SIP re-INVITE request towards the remote UE using the confirmed dialog or send SIP UPDATE 
request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the same 
INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re-INVITE request or the SIP 
UPDATE request (s) with a new SDP offer, including the media characteristics as received in the SIP 
INVITE request due to STI received on the Target Access Leg, by following the rules of 

3GPPTS 24.229 [2]; 

otherwise, if the SIP INVITE request contains a Target Dialog header field: 
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a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 

b) otherwise, either send a SIP re-INVITE request towards the remote UE using the confirmed dialog or send a 
SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by 
the same INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re-INVITE or the 
SIP UPDATE request(s) as follows: 

1) void; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 

the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg. 

If the Remote Leg is a confirmed dialog, then upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, 
the SCC AS shall: 

1) send a SIP 200 (OK) response to the initial SIP INVITE request due to STI containing a SDP answer constructed 
from the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request; 

2) consider the confirmed dialog on the Source Access Leg as being successfully transferred to the Target Access 
Leg; and 

3) if the SIP INVITE request due to STI contains: 

a Replaces header field, send a SIP BYE request on the Source Access Leg to terminate the dialog on the 
Source Access Leg, if the dialog is still active (e.g. it has not been previously released by the SC UE); or 

a Target Dialog header field and SDP of the SIP INVITE request due to STI contains: 

a) no media line whose port is set to zero, send a SIP BYE request on the Source Access Leg to terminate 
the dialog on the Source Access Leg if the dialog is still active (e.g. it has not been previously released by 
the SC UE); or 

b) any media line whose port is not zero, receive the BYE or re-INVITE request from the Source Access 
Leg in the case of removing media during full transfer or partial access transfer, respectively. 

When the SCC AS receives the BYE request on the Source Access Leg, the SCC AS shall: 

if any media are still remaining on the Source Access Leg, 

a) send 200 (OK) response for the BYE request; and 

b) send re-INVITE request to the remote UE to delete the media on the Source Access Leg by following the 
rules of 3GPP TS 24.229 [2]; and 

if there are no media on the Source Access Leg, send the 200 (OK) respones for the BYE request. 

If the SCC AS receives the 200 (OK) response about the re-INVITE request to the remote UE (created by BYE 
request), the SCC AS sends a SIP ACK request to acknowledge the received 200 (OK) response. 

When the SCC AS receives the re-INVITE request on the Source Access Leg, the SCC AS shall send a SIP 200 (OK) 
response on the Source Access Leg to acknowledge the receipt of the re-INVITE request. 

If the Remote Leg is a confirmed dialog, and if subsequent to sending the SIP re-INVITE request to the remote UE and 
prior to sending any final SIP response on the Target Access Leg, the SCC AS decides (for any reason) to reject the 
access transfer request, the SCC AS shall release the Target Access Leg (e.g. by sending a 4xx response), retain the 
Source Access Leg, and update the Remote Leg to match the Source Access Leg. 
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If the Remote Leg is an early dialog then upon receiving the SIP 2xx response to the SIP UPDATE request, the SCC AS 
shall send SIP 183 (Session Progress) response to the SIP INVITE request due to STL The SCC AS shall populate the 
SIP 183 (Session Progress) response as follows: 

a) include a SDP answer constructed from the SDP answer received in the SIP 2xx response to the SIP UPDATE 
request; 

b) if the Remote Leg is an early dialog originated by the remote UE, include a Recv-Info header field containing 
the g.3gpp.state-and-event package name; and 

c) if the Remote Leg is an early dialog originated by the SC UE, if the SIP INVITE request due to STI contains a P- 
Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media 
header field in a SIP message in the dialog of the SIP UPDATE request, include a P-Early-Media header field 
containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP 
UPDATE request. 

If the dialog on the Source Access Leg is an early dialog, then upon receiving the PRACK request for the SIP 183 
(Session Progress) response and responding with a SIP 200 (OK) response, the SCC AS shall consider the early dialog 
on the Source Access Leg as being successfully transferred to the Target Access Leg and being at the same early dialog 
stage as the early dialog on the Source Access Leg. 

NOTE 1 : All subsequent SIP requests or SIP responses originating from the remote UE and destined for the SC UE 
will be sent to the SC UE over the Target Access Leg. If the SCC AS receives any SIP request on the 
Source Access Leg, the SCC AS will not convey the received SIP request to the remote UE. 

If, upon sending the 200 (OK) response for the PRACK request, the SCC AS receives a SIP UPDATE request on the 
Source Access Leg that contains an SDP offer that indicates that the SC UE is releasing the resources for media on the 
Source Access Leg, the SCC AS will respond with a SIP 200 (OK) response containing the appropriate SDP answer, as 
specified in 3GPP TS 24.229 [2]. However, in spite of the resources being released, the dialog on the Source Access 
Leg is still active and in the early dialog phase. 

If the Remote Leg is an early dialog originated by the remote UE, then upon sending the 200 (OK) response for the 
PRACK request, and when the SCC AS: 

1) receives the SIP INFO request on the Target Access Leg(indicating that the SC UE has accepted the call) 
containing: 

a) an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package 
name; and 

b) application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package according to 
IETF RFC 6086 [54] and with the event XML element containing "call-accepted" to indicate that the called 
party has answered the call; 

the SCC AS shall: 

a) send a SIP 200 (OK) response on the Target Access Leg to acknowledge the receipt of the SIP INFO request; 

b) send SIP 200 (OK) response to the initial SIP INVITE request to the remote UE; 

c) upon sending the SIP 200 (OK) response to the SIP INFO request, send another SIP 200 (OK) response on 
the Target Access Leg that pertains to the SIP INVITE request due to STI received on the Target Access Leg; 

d) terminate the early dialog on the Source Access Leg, if still active (i.e. if not previously terminated by the SC 
UE) by sending a SIP CANCEL request on the Source Access Leg; and 

NOTE 2: The SCC AS may delay the termination of the early dialog on the Source Access Leg to let the SC UE 
terminate this early dialog. 

e) consider the early dialog becoming a confirmed dialog and successfully transferred to the Target Access Leg; 
or 

2) receives both: 
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NOTE 3: If the SC UE wants to reject the incoming call, upon initiating the transfer of the early dialog to the Target 
Access Leg, the SC UE will terminate both early dialogs, i.e. the early dialog on the Target Access Leg 
and the early dialog on the Source Access Leg. 

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and 

b) a SIP 410 (Gone) response to the initial SIP INVITE request sent on the Source Access Leg; 
the sec AS shall: 

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2]; 

b) respond to the SIP 410 (Gone) response as specified in 3GPP TS 24.229 [2]; 

c) send the appropriate SIP 4xx response to the initial SIP INVITE request received from the remote UE that 
indicates to the remote UE that the call has been rejected; and 

d) consider the early dialogs as terminated; or 

3) receives: 

NOTE 4: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will 
terminate the early dialog on the Target Access Leg, re-acquire the resources for media on the Source 
Access Leg, and accept the incoming call on the Source Access Leg. 

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and 

b) a SIP UPDATE request containing a SDP offer on the Source Access Leg, that indicates that the SC UE has 
re-acquired the resources for media on the Source Access Leg, if previously released; 

NOTE 5: If the resources for media on the Source Access Leg) have not been previously released, the SCC AS will 
not receive the SIP UPDATE request containing a SDP offer. 

the SCC AS shall: 

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2]; 

b) if a SIP UPDATE request containing a SDP offer on the Source Access Leg was received: 

A) send a SIP UPDATE request to the remote UE containing a SDP offer constructed from the SDP offer 
included in the SIP UPDATE request received on the Source Access Leg; and 

B) when the SIP 2xx response to the SIP UPDATE request containing the SDP answer is received from the 
remote UE, send a SIP 200 (OK) response to the SIP UPDATE request received on the Source Access 
Leg that includes a SDP answer constructed from the SDP answer received in the SIP 2xx response to the 
SIP UPDATE request received from the remote UE; and 

c) consider the early dialog as being transferred back to the Source Access Leg. 

If the Remote Leg is an early dialog terminated at the remote UE, then upon sending the 200 (OK) response for the 
PRACK request, if the SCC AS: 

1) receives SIP 200 (OK) response to the initial SIP INVITE request from the remote UE indicating that the remote 
UE has answered the call; 

the SCC AS shall: 

a) send a SIP 200 (OK) response toward the SC UE on the Target Access Leg that pertains to the SIP INVITE 
request due to STI; 

b) terminate the early dialog on the Source Access Leg, if still active (i.e. if not previously terminated by the SC 
UE) by sending the 410 (Gone); and 

c) consider the early dialog becoming a confirmed dialog and as successfully transferred to the Target Access 
Leg; 
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2) receives any final response (e.g. 4xx or 5xx response) from the remote UE that indicates that the remote UE has 
rejected the call, the SCC AS shall: 

NOTE 6: If the remote UE rejects the call, the SCC AS will terminate the early dialog on Source Access Leg prior 
to terminating the early dialog on the Target Access Leg. This will insure that the SC UE does not un- 
necessarily transfer the call to the Source Access Leg (e.g. re-acquires the resources) prior to the early 
dialog on the Source Access Leg being terminated. 

a) send the SIP 410 (Gone) response to the initial SIP INVITE request received on the Source Access Leg; 

b) then send a final response to the SIP INVITE due to STI that is identical to the final response (e.g. 4xx or 5xx 
response) received from the remote UE; and 

c) consider the early dialogs as terminated; or 

3) receives: 

NOTE 7: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, before 
the SC UE receives any final response on the Target Access Leg, the SC UE will terminate the early 
dialog on the Target Access Leg,, re-acquire the resources for media on the Source Access Leg, and 
update the early dialog on the Source Access Leg. 

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and 

b) a SIP UPDATE request containing a SDP offer on the Source Access Leg, that indicates that the SC UE has 
re-acquire the resources for media on the Source Access Leg, if previously released; 

NOTE 8: If the resources for media on the Source Access Leg have not been previously released, the SCC AS will 
not receive an SIP UPDATE request containing a SDP offer. 

then the SCC AS shall: 

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2]; 

b) if a SIP UPDATE request containing a SDP offer on the Source Access Leg was received: 

A) send a SIP UPDATE request to the remote UE containing a SDP offer constructed from the SDP offer 
included in the SIP UPDATE request received on the Source Access Leg; and 

B) when the SIP 2xx response to the SIP UPDATE request containing the SDP answer is received from the 
remote UE, send a SIP 200 (OK) response to the SIP UPDATE request received on the Source Access 
Leg that includes a SDP answer constructed from the SDP answer received in the SIP 2xx response to the 
SIP UPDATE request received from the remote UE; and 

c) consider the early dialog as being transferred back to the Source Access Leg. 

If the Remote Leg is an early dialog, and if subsequent to sending the SIP UPDATE request to the remote UE, and prior 
to sending any final SIP response on the Target Access Leg, the SCC AS decides (for any reason) to reject the access 
transfer request, the SCC AS shall release the Target Access Leg (e.g. by sending a 4xx response), retain the Source 
Access Leg, and update the remote leg to match the Source Access Leg. 

1 0.3.3 Additional SCC AS procedures for PS to PS access transfer winen 
MSC server assisted mid-call feature is supported 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to STI; and 

3. the SCC AS is aware: 

by local policy; or 
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by ATCF indicating support of the MSC server assisted mid-call feature; 

NOTE 1 : An ATCF can indicate support of the MSC server assisted mid-call feature by inclusion of the 

g.3gpp. mid-call feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature- 
capability indicator, in the SIP REGISTER request that created the binding of the SC UE. 

that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC 
procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call feature-capability indicator, as described in annex C, in the Feature- 
Caps header field of the SIP 2xx response to the SIP INVITE request due to STI in addition to the procedures described 
in subclause 10.3.2. 

1 0.3.4 S-CSCF releasing the source access leg during PS to PS access 
transfer 

When SCC AS receives a SIP BYE request on an existing dialog on the Source Access Leg with the status code 480 
(Temporarily Unavailable) in a Reason header field indicating that this dialog was released by the S-CSCF, the SCC AS 
shall delay the release of the dialog toward the the remote UE and retaining the information pertaining to the dialog on 
the Source Access Leg for a specific time interval. If the SCC AS: 

a) receives within this time interval an initial INVITE request (i.e. on the Targer Access Leg) indicating that this 
dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall not initiate the release of the 
dialog toward the the remote UE; or 

NOTE 1 : By retaining the information pertaining to the dialog on the Source Access Leg, and upon receiving an 
initial INVITE request (i.e. on the Targer Access Leg), the SCC AS will be able to identify the dialog on 
the Source Access Leg and the associated dialog toward the the remote UE. 

b) does not receive within this time interval an initial INVITE request (i.e. on the Targer Access Leg) indicating 
that this dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall initiate the release of the 
dialog toward the the remote UE and delete the information pertaining to the dialog on the Source Access Leg. 

NOTE 2: The time interval is defined by the operator policy. The value of 8 seconds is an appropriate value for the 
time interval. 

NOTE 3: When the UE, prior to sending the initial INVITE request on the Target Access Leg, registers new contact 
address and either uses the multiple registrations where new flow on the Target Access Leg replaces an 
old flow on the Source Access Leg or does not uses the multiple registrations, the S-CSCF will terminate 
all dialogs associated with the old constant address or old flow, as specified in 24.229. By retaining the 
information pertaining to the dialog on the Source Access Leg, the SCC AS knows which dialog is being 
replaced. 

1 0.3.5 P-CSCF releasing the source access leg during PS to PS access 
transfer 

The procedures specified in subclause 12.3.3.2 apply. 

1 0.3.6 P-CSCF releasing early dialog during PS to PS access transfer 

When the SCC AS that supports PS to PS access transfer for early dialogs, receives either: 

1) a SIP BYE request on the Source Access Leg, with the Reason header field containing a SIP 503 (Service 
Unavailable) response code, that is releasing an early dialog on the Source Access Leg originated by the SC UE; 

2) a SIP CANCEL request on the Source Access Leg, with the Reason header field containing a SIP 503 (Service 
Unavailable) response code, that is releasing an early dialog on the Source Access Leg originated by the SC UE; 
or 

3) a SIP 503 (Service Unavailable) response on the Source Access Leg, that is releasing an early dialog on the 
Source Access Leg terminating at the SC UE; 
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the sec AS shall delay the release of the associated early dialog toward the the remote UE on the Remote Leg and 
retaining the information pertaining to the early dialog on the Source Access Leg for a specific time interval. 
Subsequently, if the SCC AS: 

receives within this time interval an initial SIP INVITE request on the Target Access Leg associated with the 
early dialog on the Source Access Leg, then the SCC AS shall not initiate the release of the early dialog toward 
the the remote UE on the Remote Leg; or 

does not receive within this time interval an initial SIP INVITE request on the Target Access Leg associated 
with the early dialog on the Source Access Leg, then the SCC AS shall initiate the release of the early dialog 
toward the the remote UE on the Remote Leg and delete the information pertaining to the early dialog on the 
Source Access Leg. 

NOTE: The time interval is defined by the operator policy. The value of 8 seconds is an appropriate value for the 
time interval. 



1 1 Roles for PS-PS access transfer in conjunction with 
PS-CS access transfer 

11.1 Introduction 

This clause specifies the procedures for PS-PS access transfer in conjunction with PS-CS access transfer. Procedures are 
specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS access transfer 
with a remote end in conjunction with PS-CS access transfer with the same remote end is only possible when the UE is 
active in a single CS call with the remote end i.e. support of session transfer with more than one CS call is not provided. 

11.2 SCUE 

1 1 .2.1 SC UE procedures for PS to PS+CS access transfer 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS+CS access transfer using ICS 

This subclause applies for IMS sessions containing not only speech media component, otherwise subclause 9.2.1 
applies. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session with speech media component to be 
transferred and starting with the full-duplex session with active speech media component, the SC UE shall send a SIP 
INVITE request to the SCC AS as specified for call origination for ICS UE using Gm in 3GPP TS 24.292 [4]. The SC 
UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full media transfer in 
subclause 10.2.1 with the following exceptions: 

The SC UE shall indicate in the SIP INVITE request that the speech media component is using CS bearer with 
its corresponding media description. 

When sending the SIP INVITE request for the full-duplex sessions with inactive speech media component and if 
precondition is used, the SC UE shall indicate that the related local preconditions for the speech media 
component are met. 

For the full-duplex session with active speech media component, upon receiving the PSI DN from the SCC AS, 
the SC UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up 
the CS bearer. 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 75 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

If service control over Gm for the CS bearer is retained on the source access leg, the SC UE shall: 

send an SIP INVITE request as specified for partial session transfer in subclause 10.2.2. indicating transfer of 
non-speech media to the target access leg; and 

send a SIP re-INVITE request over the source access leg indicating that the speech media component is to be 
transferred to a CS bearer as described in 3GPP TS 24.292 [4] subclause 8.2.2.2. If other media components are 
retained or added on the source access leg, then these are included in the SDP offer. 

For the full-duplex session with active speech media component, upon receiving the SCC AS PSI DN from the SCC 
AS, the SC UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up 
the CS bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS+CS access transfer not using ICS 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC server assisted mid-call feature as 
specified in subclause 9.2.1 A, then access transfer is only possible when the UE is active in a single full-duplex session 
with active speech media component. 

For the non-speech components to be transferred to the PS Target Access Leg, the SC UE shall send a SIP INVITE 
request to the SCC AS as specified for PS-PS access transfer with partial media transfer in subclause 10.2.1. For the 
speech media component to be transferred to the CS Target Access leg, the SC UE shall send to the SCC AS a CC 
SETUP message as specified in 3GPP TS 24.008 [8]. When sending the CC SETUP message, the SC UE shall populate 
the CC SETUP message as follows: 

1) the called party BCD number information element set to the STN; 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164". in the Called Party BCD 
Number information element. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 

3GPPTS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS access transfer with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech media component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
access transfer with partial media transfer in subclause 10.2.2 to indicate that the speech media component is still 
maintained on the Source Access Leg. 

1 1 .2.1 .4 SC UE procedures for PS to PS+CS access transfer not using ICS with IVISC 
server assisted mid-call feature 

In addition to the procedures described in subclause 1 1.2.1.3 the SC UE shall: 

act as described in subclause 9.2.1 A; and 

if the MSC server assisted mid-call feature is applied, transfer the non-speech media components of the 
additional transferred session to the PS Target Access Leg as specified for PS-PS access transfer with partial 
media transfer in subclause 10.2.2. 
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1 1 .2.2 SC UE procedures for PS+CS to PS access transfer 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the SIP 2xx 
response for the initial SIP INVITE request to establish this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
access transfer. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS access transfer using ICS 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each full-duplex session with speech media component to be transferred and starting with 
the session with active speech media component, the SC UE shall send a SIP INVITE request to the SCC AS in 
accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE 
request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1. The SC UE shall indicate in 
the SIP INVITE request that the speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS+CS to PS access transfer not using ICS 

If the original sessions are not established using ICS capabilities, then access transfer is only possible when the SC UE 
has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request to 
the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

the Require header field including "replaces" option tag; 

the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains media 
components in the following order: 

1) the same number of media lines, each corresponding to one of the media components in the session on the PS 
Source Access Leg; For each media line the SC UE shall indicate the same media type as its corresponding 
media component in the original session and indicate at least one codec that was negotiated during the 
original session. If the SC UE determines to remove a media component during the transfer, then the SC UE 
shall set the media line for this media component to include a port number with value zero; 

2) one speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) if the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs each new media component. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 
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1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URL In the procedures below, such requests are known as "SIP INVITE requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URI. In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to two STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS access transfer 

This subclause does not apply to reception of a SIP INVITE request due to STI with a CS media. 

When the SCC AS receives a SIP INVITE request due to STI with PS and CS media on the Target Access Leg, the 
SCC AS shall follow the PS-PS Access Transfer procedures specified in subclause 10.3.2. with the following 
exceptions: 

If the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall follow 
the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and 
wait for the SC UE to set up CS bearer before sending re-INVITE to the remote UE. 

The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

If service control over Gm is retained on the source access leg, and the SCC AS receives a re-INVITE request 
indicating CS bearer on an existing session, the SCC AS shall follow procedures as described in 
3GPP TS 24.292 [4] subclause 8.4.2 to send the PSI DN to the SC UE and wait for the SC UE to set up CS 
bearer before sending re-INVITE to the remote end. 

The SCC AS shall include a new SDP offer in the re-INVITE request, following the rules specified in 
3GPP TS 24.229 [2], containing the following media information: 

the media characteristics as received in the SIP INVITE request due to STI with PSh-CS media received on 
the Target Access Leg for media streams whose port is not set to zero; and 

the media characteristics as received in the SIP re-INVITE request for media streams whose port is not set to 
zero. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS Access Transfer procedures specified in subclause 9.3.2. However, as the Source Access Leg contains 
media components other than speech media component, the SCC AS does not initiate release for Source Access Leg. 

1 1 .3.3 SCC AS procedures for PS+CS to PS access transfer 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS access transfer procedures specified in subclause 10.3.2. 
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When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 
associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) or Target-Dialog header field (see IETF RFC 4538 [11]) of 
the SIP INVITE request with an ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a 
SIP 2xx response to the initial SIP INVITE request has been sent or received; 

b) a different ongoing SIP dialog with active speech media component: 

if the SCC AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPPTS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 



12 Roles for PS-CS access transfer, Single Radio 



12.1 Introduction 



This clause specifies the procedures for PS-CS SRVCC and vSRVCC access transfer. Procedures are specified for the 
SC UE, the SCC AS, the EATF, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC and the 
ATCF. 

For SC UE or SCC AS not supporting ICS procedures, PS-CS SR-VCC access transfer enables transfer of 

single session with active speech media component; and 

up to one session with active speech media component and up to one session with inactive speech media 
component when the MSC Server assisted mid-call feature is supported. 

For SC UE or SCC AS, PS-CS access transfer in vSRVCC enables the transfer of a single session with active speech 
and video media components. 

In order to fulfil the requirements for PS-CS SRVCC or vSRVCC access transfer for calls in alerting state, the SC UE 
needs to be: 

engaged in a session with speech media component in early dialog state before PS to CS SRVCC access transfer 
is performed; or 

engaged in a session with active speech media component and active video media component in early dialog 
state before vSRVCC access transfer is performed 

according to the following conditions: 

a SIP 180 (Ringing) response for the initial SIP INVITE request to establish this session has been sent or 
received; and 
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a SIP final response for the initial SIP INVITE request to establish this session has not been sent or received. 

If one of the dialogs meets the above conditions then after successful completion of the PS to CS SRVCC procedures: 

Subclauses 12.2.2, 12.2.3, 12.2.3A and 12.2.4 shall be followed for a SC UE engaged in one or more ongoing 
sessions. 

Subclauses 12.2.3B and 12.2.4 shall be followed for a SC UE that is engaged in a session in early dialog state. 

If one of the dialogs meets the above conditions then after successful completion of the vSRVCC procedures: 

Subclauses 12.2A.2, 12.2A.3, 12.2A.4 and 12.2A.6 shall be followed for a SC UE engaged in one or more 
ongoing sessions. 

Subclauses 12.2A.5 and 12.2A.6 shall be followed for a SC UE that is engaged in a session in early dialog state. 

NOTE: The UE determines from the handover command sent by the eNodeB as specified in 

3GPP TS 36.331 [62] that the network intends to perform SRVCC handover or vSRVCC handover, based 
upon whether the radio resources allocated are for a TSl 1 bearer or a BS30 bearer. 

12.2 SC UE procedures for PS to CS access trarisfer, PS to CS 
SRVCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before PS to CS SRVCC access transfer is performed. By 
an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

In the PS to CS SRVCC session continuity procedures the SC UE shall consider only sessions where the following 
applies 

1 . the session does have a speech media component; and 

2. the speech media is carried over PS bearer with traffic-class conversation with source statistics descriptor 
="speech" as specified in 3GPP TS 23.107 [66]) or over a PS bearer with QCI=1 as specified in 

3GPPTS 23.203 [65]). 

for access transfer. Sessions considered for PS to CS SRVCC procedures are regarded as full-duplex. 

12.2.2 ICS-based 

If: 

SC using ICS is enabled; 

the Gm reference point is retained upon PS handover procedure; 

- the SC UE is using ICS capabiHties as defined in 3GPP TS 24.292 [4]; and 

- PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 

the SC UE, in order to add Gm control for the newly established CS session, shall: 

send a SIP re-INVITE request for each session with speech media component to be transferred, starting with the 
session with active speech media component that was most recently made active; and 

within the SDP offer indicate the media line for the speech media component (active or held) as an speech 
media component over circuit switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition 
mechanism is used, the SC UE shall indicate the related local preconditions as met. 
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NOTE: Within PS to CS SRVCC the handover is performed on PS level. Due to this, the SIP dialog established 
over the source PS access network stays the same after PS to CS SRVCC procedures, e.g. the IP address 
of the UE, the Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to 
add ICS-control for the CS bearer. 

12.2.3 Not based on ICS 

After successful PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed, if the SC UE 
is not using ICS capabilities and the SC UE does not apply the MSC Server assisted mid-call feature as specified in 
subclause 12.2. 3A, the SC UE shall replace the ongoing session with active speech media component which was made 
active most recently with the newly established CS voice call. 

NOTE 1 : In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted 
mid-call feature, only the ongoing session with active speech media component which was made active 
most recently is transferred from PS to CS audio. 

In addition, if: 

the Gm reference point is retained upon PS handover; and 

NOTE 2: The SC UE knows that the Gm reference point is retained upon PS handover if, following handover, the 
SC UE has a dedicated PDP context for SIP signalling or has a general-purpose PDP context to carry the 
IM CN subsystem-related signalUng, as described in 3GPP TS 24.229 [2] annex B.2.2.1. 

there are one or more remaining non-speech media component(s) in the IMS session other than the speech media 
component which were transferred to the CS Target Access Leg; 

the SC UE shall: 

send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 

indicate in the SDP offer the speech media component as removed. 

NOTE 3: The SC UE can still send a SIP re-INVITE request if there are no remaining media components in the 
IMS session. 

12.2.3A Not based on ICS with MSC Server assisted mid-call feature 

After successful PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]), if: 

1. the SC UE is not using ICS capabilities; 

2. the SC UE supports the MSC Server assisted mid-call feature; and 

3. one of the following is true: 

A. there is at least one ongoing session with active speech media component and the Feature-Caps header field 
received by the SC UE at the establishment of the ongoing session with active speech media component, 
which has been most recently made active, includes the g.3gpp. mid-call feature-capability indicator as 
described in annex C; or 

B. there is no ongoing session with active speech media component and the Feature-Caps header field received 
by the SC UE at the establishment of the ongoing session with inactive speech media component which 
became inactive most recently includes the g.3gpp. mid-call feature-capability indicator as described in 
annex C. 

then the SC UE shall apply the MSC Server assisted mid-call feature as follows: 

1. if two or more ongoing sessions with active speech media component exist, the SC UE shall: 

A) replace the speech media components of the ongoing session with active speech media component which was 
most recently made active with the newly established active CS voice call; and 

B) replace the speech media component of the ongoing session with active speech media component which was 
made active second most recently with the newly established held CS voice call; 
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2. if one ongoing session with active speech media component exists and one or more ongoing sessions with 
inactive speech media component exist, the SC UE shall: 

A) replace the speech media components of the ongoing session with active speech media component with the 
newly established active CS voice call; and 

B) replace the speech media component of the ongoing session with inactive speech media component which 
was most recently made inactive with the newly established held CS voice calls; 

3. if one ongoing session with active speech media component exists and no ongoing sessions with inactive speech 
media component exist, the SC UE shall replace the speech media component of the ongoing session with active 
speech media component with the newly established active CS voice call; and 

4. if no ongoing session with active speech media component exists and one or more ongoing sessions with inactive 
speech media component exist, the SC UE shall replace the speech media component of the ongoing session 
with inactive speech media component which became inactive most recently with the newly established held CS 
voice call. 

For each session, the SC UE shall proceed as specified in subclause 12.2.3. 

If two sessions are transferred, the SC UE shall associate the additional transferred session with CS call with transaction 
identifier 1 and TI flag value as in mobile terminated call. 

NOTE: The session with active speech media component transaction identifier value is described in 
3GPP TS 24.008 [8] 

If a transferred session is with conference focus then the SC UE shall associate the transaction identifiers to participants 
as in subclause 9.2. lA. 

If single session with inactive speech media component is transferred, the SC UE shall associate the transferred session 
with CS call with transaction identifier and TI flag value as in mobile terminated call. 



12.2.3B Alerting call 



12.2.3B.1 General 

The SC UE shall apply the procedures in subclauses 12.2.3B.3 for access transfer for calls in alerting state if: 

1) the SC UE supports single radio PS to CS access transfer for calls in alerting state; and 

2) there are one or more early dialogs created by the same SIP INVITE request with at least one dialog that is an 
early dialog supporting a session with active speech media component where the SC UE: 

has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.srvcc-alerting media feature tag (as described in annex C); and 

has received a Feature-Caps header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C) 

The SC UE shall apply the procedures in subclauses 12.2.3B.4.1 for access transfer for calls in alerting state if: 

1) the SC UE supports single radio PS to CS access transfer for calls in alerting state; 

2) there are several dialogs supporting more than one session where: 

a) there is at least one dialog supporting a session in the confirmed state with active speech media component; 

b) there are one or more early dialogs created by the same SIP INVITE request that has at least one dialog that 
is an early dialog supporting a session with active speech media component where the SC UE: 

- has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.srvcc-alerting media feature tag (as described in annex C); and 

has received a Feature-Caps header field in a SIP INVITE request or 180 (Ringing) response containing 
the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C) 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 82 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

1 2.2.3B.1 A Considerations for MSC server assisted mid-call feature 

If the SC UE supports both access transfer for calls in alerting state and the MSC server assisted mid-call feature then in 
addition to supporting the procedures specified in subclauses 12.2.3B.3 and 12.2.3B.4.1, it shall apply the procedures 
specified in subclause 12.2.3B.4.2 where there are several dialogs supporting more than one session according to the 
following conditions: 

1) there are no dialogs in the confirmed state supporting a session with active speech media component; 

2) there is at least one dialog in the confirmed state supporting a session with inactive speech media component; 

3) there is only one session with active speech media component, that has at least one dialog that is an early dialog; 
and 

4) theSCUE: 

has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.srvcc-alerting media feature tag (as described in annex C); 

has sent a Contact header field in a SIP INVITE request or 2xx response containing the g.3gpp. mid-call 
media feature tag (as described in annex C); 

has received a Feature-Caps header field in a SIP INVITE request or 180 (Ringing) response containing the 
gjgpp.srvcc-alerting feature-capability indicator; and 

has received a Feature-Caps header field in a SIP INVITE request or 2xx response containing the 
g.3gpp. mid-call feature -capability indicator. 

1 2.2.3B.2 Assignment of Transaction Identifiers to the transferred sessions 

If the SC UE applies the procedures in subclause 12.2. 3B. 3 and the SC UE only has a single call in alerting state 
following access transfer, then the SC UE shall associate this session with transaction identifier value and TI flag as 
described in 3GPP TS 24.008 [8]. 

If the SC UE applies the procedures in subclause 12.2. 3B.4 and the SC UE has an established session and an additional 
session in alerting state following access transfer, then the SC UE shall associate the transferred session that was in 
alerting state with CS call with transaction identifier 1 and TI flag value as in mobile terminated call. 

NOTE: For the procedures in subclause 12.2.3B.4.2, the held transaction identifier value is described in 

subclause 12.2. 3A as for single inactive session transfer and the active session transaction identifier value 
is described in 3GPP TS 24.008 [8] 

1 2.2.3B.3 Single call in alerting state 
12.2.3B.3.1 Terminating call in alerting phase 

IftheSCUE: 

has received a terminating call which is in the early dialog state according to the conditions in subclauses 12. 1 
and 12.2.3B.l;and 

successfully performs access transfer to the CS domain; 

then the UE continues in Ringing state in CS, i.e. UE moves to Call Received (U7) state as described in 
3GPPTS 24.008 [8]. 

IftheSCUE: 

has received a terminating call which is in the early dialog state according to the conditions in subclauses 12.1 
and 12.2.3B.l;and 

has sent a SIP 200 (OK) response (i.e. user answers the call when in the PS domain) prior to successfully 
performing access transfer to the CS domain; 
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then the UE sends a CC CONNECT message and transitions to Active (UIO) state as described in 3GPP TS 24.008 [8]. 

12.2.3B.3.2 Originating call in alerting phase 

If the SC UE has initiated an outgoing call which is in the early dialog state according to the conditions in 
subclauses 12.1 and 12.2.3B.1 and the SC UE successfully performs access transfer to the CS domain, then the UE 
continues in Ringing state in CS, i.e. UE moves to Call Delivered (U4) state as described in 3GPP TS 24.008 [8]. If the 
UE has received a SIP 180 (Ringing) response, depending on the type of the ringing tone, the UE behaves as following: 

if the SC UE is playing the locally generated ringing tone, then the UE keeps playing the locally generated 
ringing tone; and 

if the SC UE is playing network-generated ringing tone as early media, then the UE attaches the user connection 
to the MSC server, as specified in 3GPP TS 24.008 [8]. 

12.2.3B.4 Established call with a session in alerting state 
12.2.3B.4.1 Active session with incoming call in alerting phase 

IftheSCUE: 

has a session with an active speech media component and has received an incoming call (waiting) which is in the 
early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and 

successfully performs access transfer to the CS domain; 

then the UE moves to Call Received (U7) state (defined in 3GPP TS 24.008 [8]) for the incoming call (waiting) (i.e. 
continues in Ringing state in CS for the incoming call waiting). 

12. 2. SB. 4. 2 Held session with new outgoing call in alerting phase 

IftheSCUE: 

has a session with an inactive speech media component and has initiated a new outgoing call which is in the 
early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and 



successfully performs access transfer to the CS domain; 



then: 



- the UE moves to Call Delivered (U4) state (defined in 3GPP TS 24.008 [8]) for the new outgoing call (i.e. UE 
continues in Ringing state in CS for the outgoing call). 

- the UE moves to Call Active (UIO) state (defined in 3GPP TS 24.008 [8]) and Call Held Auxiliary State (defined 
in 3GPP TS 24.083 [43]) for the held call. 

12.2.4 Abnormal cases 
12.2.4.1 Confirmed dialog 

If the SC UE engaged in one or more ongoing IMS sessions and: 

receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re- 
establishment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] depending on the access in 
use; or 

does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command 
from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 
3GPPTS 25.331 [61]); 

then the SC UE shall send a SIP re-INVITE request containing: 

1) an SDP offer, including the media characteristics as used in the existing dialog; and 
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2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in 
IETF RFC 3326 [57] and with reason-text text set to either "handover cancelled" or "failure to transition to CS 
domain" ; 

by following the rules of 3GPP TS 24.229 [2] in each transferred session. 

12.2.4.2 Early dialog 

If the SC UE is engaged in a session in early dialog state and: 

receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re- 
estabhshment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] depending on the access in 
use; or 

does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command 
from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 
3GPPTS 25.331 [61]); 

then the SC UE shall send a SIP UPDATE request containing: 

1) an SDP offer, including the media characteristics as used in the existing dialog; and 

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in 
IETF RFC 3326 [57], and with reason-text set to either "handover cancelled" or "failure to transition to CS 
domain" ; 

by following the rules of 3GPP TS 24.229 [2] in each transferred session. 

12.2A SC UE procedures for PS to CS access transfer, vSRVCC 
12.2A.1 General 

The SC UE may be engaged in one or more ongoing sessions before vSRVCC access transfer is performed. By an 
ongoing session, it is meant a session for which the response to the initial SIP INVITE request to establish this session 
has been sent or received. 

In the vSRVCC session continuity procedures the SC UE shall consider only sessions where the following applies: 

1 . the SIP dialog contains speech and video media components supporting a real time video session synchronized 
with speech as defined in 3GPP TS 22.173 [24], which includes the codecs for speech and video as specified in 
3GPPTS 26.114 [68]; and 

2. the speech media is carried over a PS bearer with QCI=1 as specified in 3GPP TS 23.203 [65]); 
for access transfer. Sessions considered for vSRVCC procedures are regarded as full-duplex. 

12.2A.2 ICS-based 

If: 

SC using ICS is enabled; 

the Gm reference point is retained upon PS handover procedure; and 

NOTE 1 : The SC UE knows that the Gm reference point is retained upon PS handover if, following handover, the 
SC UE has a "dedicated PDP context for SIP signalling" or has a "general-purpose PDP context" to carry 
the IM CN subsystem-related signalling, as described in 3GPP TS 24.229 Annex B.2.2.1. 

- the SC UE is using ICS capabilities as defined in 3GPP TS 24.292 [4]; 

- vSRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
then the SC UE, in order to add Gm control for the newly established CS session, shall: 
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send a SIP re-INVITE request for each session with only speech media component or with both speech and 
video media components to be transferred starting with the session with active speech and video media 
components that was most recently made active; 

within the SDP offer for sessions with speech and video media components, indicate the media lines for the 
speech and video media components as speech and video media components over circuit switched bearer in 
accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall indicate the 
related local preconditions as met; and 

within the SDP offer for sessions with only speech media component, indicate the media lines for the speech 
media component as speech media component over circuit switched bearer in accordance with 
3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall indicate the related local 
preconditions as met; 

NOTE 2: The SIP dialog established over the source PS access network stays the same after vSRVCC procedures, 
e.g. the IP address of the UE, the Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE 
needs to be sent to add ICS-control for the CS bearer. 

12.2A.3 Not based on ICS 

After successful vSRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed, if the SC UE is not 
using ICS capabilities, the SC UE shall replace the session with active speech and video media components which was 
most recently made active with the newly established CS voice/video call. 

NOTE 1: In the case when ICS is not supported or used, only the ongoing session with active speech and video 
media components which was most recently made active is transferred from PS to CS. 

In addition, if: 

the Gm reference point is retained upon PS handover; and 

NOTE 2: The SC UE knows that the Gm reference point is retained upon PS handover if, following handover, the 
SC UE has a dedicated PDP context for SIP signalling or has a general-purpose PDP context to carry the 
IM CN subsystem-related signalUng, as described in 3GPP TS 24.229 [2] annex B.2.2.1. 

there are one or more remaining media component(s) in the IMS session other than the speech and the video 
media components which were transferred to the CS Target Access Leg; 

the SC UE shall: 

send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 

indicate in the SDP offer the speech and video media components as being removed. 

NOTE 3: The SC UE can still send a SIP re-INVITE request if there are no remaining media components in the 
IMS session. 

12.2A.4 Void 



12.2A.5 Alerting call 



If the conditions in subclause 12.2.3B.1 for the application of subclause 12.2.3B.3 are satisfied for a session with active 
speech media component and active video media component prior to the successful completion of the vSRVCC 
procedures (as described in 3GPP TS 24.008 [8]), then after the successful completion of the vSRVCC handover 
procedures, the SC UE shall apply the procedures specified in subclause 12.2. 3B. 3 

12.2A.6 Abnormal cases 

IftheSCUE: 

receives a NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re-establishment 
required" as described in 3GPP TS 24.301 [52]; or 
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does not successfully transition to UTRAN after it receives the handover command (as described in 
3GPPTS 36.331 [62]); 

Then: 

if the SC UE is engaged in one or more ongoing IMS sessions, the SC UE shall send a SIP re-INVITE request in 
accordance with subclause 12.2.4.1; and 

if the SC UE is engaged in a session in early dialog state, the SC UE shall send a SIP UPDATE request, in 
accordance with subclause 12.2.4.2. 

1 2.2B SC UE procedures for CS to PS SRVCC 
12.2B.1 Distinction of requests 

The SC UE needs to distinguish the following SIP requests: 

1) SIP REFER request: 

A) with the Refer-Sub header field containing "false" value; and 

B) containing application/vnd.3gpp.mid-call+xml MIME body or the application/vnd.3gpp.state-and-event- 
info+xml MIME type; 

In the procedures below, such requests are known as "SIP REFER requests for transfer of an additional session". 

2) SIP INFO request: 

A) with the Info-Package header field containing the g.3gpp.state-and-event; and 

B) containing an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 with the 
state-info XML element containing "early" and direction XML element containing "receiver"; 

In the procedures below, such requests are known as "SIP INFO requests for transfer of incoming early session". 

12.2B.2 First call transfer 
12.2B.2.1 General 

If SC UE supports the CS to PS SRVCC, upon receiving information from the lower layers that the CS to PS SRVCC 
access transfer is initiated, the SC UE shall: 

1) if a CS call in Active (UIO) state (defined in 3GPP TS 24.008 [8]) and Idle auxihary state (defined in 
3GPP TS 24.083 [43]) exists and if the ATGW transfer details were received from the lower layers: 

A) determine the active call being transferred as a CS call in Active (UIO) state (defined in 3GPP TS 24.008 [8]) 
and Idle auxiliary state (defined in 3GPP TS 24.083 [43]); 

B) start rendering speech media of the determined active call being transferred received according to the UE 
information for CS to PS SRVCC sent to the network (see subclause 6.2.3); and 

C) start sending speech media of the determined active call being transferred according to the ATGW 
information for CS to PS SRVCC received from the network (see subclause 6.2.3) where the address type, 
the connection address and the transport port to which the media stream is sent are replaced with the ATGW 
transfer details received from the lower layers; and 

2) send a SIP INVITE request to STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP 
INVITE request with: 

A) Request-URI set to the STI-rSR received during registration (see subclause 6.2.1); 

B) SDP offer set to the UE information for CS to PS SRVCC sent to the network (see subclause 6.2.3); 
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C) if a GRUU was received at registration, include the public GRUU or temporary GRUU in the Contact header 
field; 

D) if the SC UE supports the PS to CS SRVCC with the MSC server assisted mid-call feature, include the 
g.3gpp. mid-call media feature tag in the Contact header field; and 

E) if the SC UE supports the PS to CS SRVCC for calls in alerting phase, include the g.3gpp.srvcc-alerting 
media feature tag in the Contact header field; 

F) if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature: 

a) the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; and 

b) the Accept header field containing the application/vnd.3gpp.mid-callH-xml MIME type; and 

G) if the SC UE supports CS to PS SRVCC for calls in alerting phase: 

a) the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20], if not 
inserted already; 

b) an Accept header field containing the application/vnd.3gpp.state-and-event-infoH-xml MIME type; 

c) a Recv-Info header field containing the g.3gpp.state-and-event package name; and 

d) a Supported header field with " lOOrel" option tag. 

Upon receiving a SIP Ixx or 2xx response to the SIP INVITE request to STI-rSR, the SC UE shall associate the dialog 
of the SIP Ixx or 2xx response with the CS call where the transaction identifier sent by MSC server equals to the value 
of the g.3gpp.ti feature-capability indicator of a Feature-Caps header field of the SIP response. If the SC UE is not 
aware of such CS call, the SC UE shall release or cancel the dialog established by the SIP Ixx or 2xx response to the 
SIP INVITE request to STI-rSR. 

1 2.2B.2.2 Transfer of call with active speech media component 

No additional procedures in addition to the procedures in subclause 12.2B.2.1 apply. 

12.2B.2.3 Transfer of call with inactive speech media component 

No additional procedures in addition to the procedures in subclause 12.2B.2.1 apply. 

NOTE: If the network associates the SIP INVITE request to STI-rSR with session with inactive speech media 
component, the SDP answer will contain a=recvonly or a=inactive. 

1 2.2B.2.4 Transfer of originating alerting call 

No additional procedures in addition to the procedures in subclause 12.2B.2.1 apply. 

1 2.2B.2.5 Transfer of terminating alerting call 

If SC UE supports the CS to PS SRVCC and if the SC UE supports the CS to PS SRVCC for calls in alerting phase, in 
addition to the procedures in subclause 12.2B.2.1, upon receiving the SIP INFO request for transfer of incoming early 
session inside an early dialog created with the SIP INVITE request due to STI-rSR, the SC UE shall: 

1) send SIP 200 (OK) response to the SIP INFO request; and 

2) consider the SIP dialog to be the transferred incoming early session. 

When the served user accepts the transferred incoming early session or if the user has accepted it already, the SC UE 
shall send a SIP INFO request accepting the session inside the early dialog created with the SIP INVITE request due to 
STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INFO request with: 

1) an Info-Package header field with 3gpp.state-and-event info package name; and 
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2) application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to 

IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 with the event XML element 
containing "call-accepted". 

When the served user rejects the transferred incoming early session, the SC UE shall send a SIP CANCEL request 
cancelling the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP 
CANCEL request with a Reason header field containing protocol "SIP" and the "cause" parameter indicating the 
selected status code and the "text" parameter indicating the selected reason phrase. 

12.2B.3 Additional call transfer 
12.2B.3.1 General 

If SC UE supports the CS to PS SRVCC, if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature 
or the CS to PS SRVCC for calls in alerting phase then upon receiving a SIP REFER request for transfer of an 
additional session within dialog established by the SIP INVITE request to STI-rSR, the SC UE shall: 

1) handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; 

2) send a SIP INVITE request for transfer of an additional session according to 3GPP TS 24.229 [2] and 
IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 

A) header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B) the SDP offer with: 

a) the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b) each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c) port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d) media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request; 

NOTE: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

C) if a GRUU was received at registration, include the public GRUU or temporary GRUU in the Contact header 
field; 

D) if the SC UE supports the PS to CS SRVCC with the MSC server assisted mid-call feature, include the 
g.3gpp. mid-call media feature tag in the Contact header field; 

E) if the SC UE supports the PS to CS SRVCC for calls in alerting phase, include the g.3gpp.srvcc-alerting 
media feature tag in the Contact header field; and 

F) if the SC UE supports the CS to PS SRVCC for calls in alerting phase: 
a) a Supported header field with " lOOrel" option tag.; and 

3) if the SC UE supports the CS to PS SRVCC for calls in alerting phase and if the REFER request contains a XML 
body compliant to the XML schema specified in the annex D.2 with the state-info XML element containing 
"early" and direction set to "receiver" then consider the SIP dialog to be transferred incoming early session. 

Upon receiving a SIP Ixx or 2xx response to the SIP INVITE request for transfer of an additional session, the SC UE 
shall associate the dialog of the SIP Ixx or 2xx response with the CS call where the transaction identifier sent by MSC 
server equals to the value of the g.3gpp.ti feature-capability indicator of a Feature-Caps header field of the SIP 
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response. If the SC UE is not aware of such CS call, the SC UE shall release or cancel the dialog established by SIP Ixx 
or 2xx response to the SIP INVITE request for transfer of an additional session. 

1 2.2B.3.2 Transfer of call with active speech media component 

No additional procedures in addition to the procedures in subclause 12.2B.3.1 apply. 

12.2B.3.3 Transfer of call with inactive speech media component 

No additional procedures in addition to the procedures in subclause 12.2B.3.1 apply. 

NOTE: If the network associates the SIP INVITE request to STI-rSR with session with inactive speech media 
component, the SDP answer will contain a=recvonly or a=inactive. 

1 2.2B.3.4 Transfer of originating alerting call 

No additional procedures in addition to the procedures in subclause 12.2B.3.1 apply. 

1 2.2B.3.5 Transfer of terminating alerting call 

If SC UE supports the CS to PS SRVCC, if the SC UE supports the CS to PS SRVCC for calls in alerting phase, in 
addition to the procedures in subclause 12.2B.3.1, when the served user accepts the transferred incoming early session 
or if the user has accepted it already, the SC UE shall send a SIP INFO request accepting the session inside the early 
dialog created with the SIP INVITE request for transfer of an additional session according to 3GPP TS 24.229 [2]. The 
SC UE shall populate the SIP INFO request with: 

1) an Info-Package header field with 3gpp.state-and-event info package name; and 

2) application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to 
IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 with the event XML element 
containing "call-accepted". 

If the SC UE supports the CS to PS SRVCC for calls in alerting phase then when the served user rejects the transferred 
incoming early session, the SC UE shall send a SIP CANCEL request cancelling the SIP INVITE request for transfer of 
an additional session according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP CANCEL request with: 

1) a Reason header field containing protocol "SIP" and the "cause" parameter indicating the selected status code 
and the "text" parameter indicating the selected reason phrase. 

12.3 sec AS 
12.3.0 General 

In the Single Radio access transfer procedures the SCC AS shall only consider sessions that have the necessary media 
components that meet the criteria for performing Single Radio access transfer as defined in subclause 4.2.2. 

1 2.3.0A Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for PS 
to CS SRVCC: 

SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URI and containing an SDP offer with active speech media component only. These SIP INVITE requests 
originate from the MSC server. In the procedures below, such requests are known as "SIP INVITE requests due 
to STN-SR". 

- SIP INVITE requests routed to the SCC AS due to ATU-STI for PS to CS SRVCC in the Request-URL In the 
procedures below, such requests are known as "SIP INVITE requests due to ATU-STI for PS to CS SRVCC". 
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- SIP INVITE request routed to the SCC AS contains the additional transferred session SCC AS URI for PS to CS 
SRVCC in the Request-URI, such a request is in this document known as "SIP INVITE request transferring 
additional session for PS to CS SRVCC". 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for 
vSRVCC: 

SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URI and containing an SDP offer with both active speech and video media components only, which includes the 
default codecs for speech and video (as specified in 3GPP TS 26.1 1 1 [69]). These SIP INVITE requests originate 
from the MSC server. In the procedures below, such requests are known as "SIP INVITE requests for audio and 
video due to STN-SR". 

1 2. 3. OB Determine the transferable session set 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg the SCC AS shall 
determine the transferable session set. 

A session is in the transferable session set when the session: 

1) is a session of the SC UE whose private user identity is associated with the C-MSISDN that is contained in the 
P-Asserted-Identity header field of the SIP INVITE request; and 

2) is a session with speech media component. 
The SCC AS shall: 

1) if the conditions for applying MSC server assisted mid-call feature described in subclause 12.3.2.1 are fulfilled, 
follow the procedures in subclause 12.3.2; 

2) if the conditions in subclause 12.3.4. 1 for applying the PS to CS transfer of a call in an alerting phase feature in 
subclauses 12.3.4.2 or 12.3.4.3 are fulfilled, follow the procedures in subclause 12.3.4.2 or 12.3.4.3; and 

3) if none of the conditions 1) or 2) above are fulfilled follow the procedure in subclause 12.3. 1 . 

1 2.3.1 SCC AS procedures for PS to CS access transfer, PS to CS SRVCC 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg the SCC AS shall associate 
the SIP INVITE request with a session: 

within the transferable session set; 

with active speech media component that was most recently made active; and 

the related dialog is in confirmed state. 

If no confirmed dialogs supporting a session with active speech media component exists in the transferable session set 
the SCC AS shall: 

1) send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR; 

2) if the transferable session set contains dialogs supporting sessions with speech media component (inactive 
speech media component or in an early dialog state): 

a) if the speech media component is the only media component in the dialog then release the remote leg as 
specified in 3GPP TS 24.229 [2]; and 

b) if the speech media component is not the only media component in the dialog then modify the remote leg and 
remove the speech media component as specified in 3GPP TS 24.229 [2]. 

If confirmed dialogs supporting a session with active speech media component exist in the transferable session set the 
SCC AS shall send a SIP re-INVITE request towards the remote UE and in a new SDP offer, include the media 
characteristics as received in the SIP INVITE request due to STN-SR, by following the rules of 3GPP TS 24.229 [2]. 
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Upon receiving the 2xx response to the re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP 
INVITE request due to STN-SR on the target access leg using the relevant media parameter of the SDP answer in the 
received response, by following the rules of 3GPP TS 24.229 [2]. 

If the SCC AS supports SRVCC for calls in alerting phase and if the conditions specified in subclause 12.3.4.1 for a 
session in the transferable session set are fulfilled, the SCC AS shall follow the procedures in the subclause 12.3.4.4 and 
then continue with the procedures in this subclause. 

The SCC AS shall remove non-tranferred audio components and superfluous session as specified in subclause 12.3.8. 

1 2.3.2 SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature, PS to CS SRVCC 

12.3.2.1 General 

The SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 12.3.2.2 if: 

1 . one of the conditions are true: 

a. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to STN-SR, the 
SCC AS local policy requires delaying application of the MSC Server assisted mid-call feature for a time 
given by local policy and the transfer request for the session with inactive speech media component has not 
been received within a time given by local policy after the reception of the SIP INVITE request due to STN- 
SR; 

b. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to STN-SR and 
the SCC AS local policy does not require delaying application of the MSC Server assisted mid-call feature 
for a time given by local policy; or 

c. the SC UE did not include the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the 
Contact header field during establishment of the session associated with the SIP INVITE request due to STN- 
SR; 

2. the Contact header field of the SIP INVITE request due to STN-SR includes the g.3gpp. mid-call media feature 
tag as specified in annex C; 

3. one of the following is true for dialogs in the transferable session set: 

A. at least one confirmed dialog supporting a session with active speech media component exists and the 
following is true for the confirmed dialog supporting a session with the active speech media component 
which has been most recently made active: 

the Contact header field provided by the SC UE at the establishment of the dialog includes the 
g.3gpp. mid-call media feature tag as described in annex C; and 

- the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog 
included g.3gpp. mid-call feature-capability indicator; or 

B. no confirmed dialog supporting a session with active speech media component exists and the following is 
true for the confirmed dialog supporting a session with inactive speech media component which became 
inactive most recently: 

the Contact header field provided by the SC UE at the establishment of the dialog includes the 
g.3gpp. mid-call media feature tag as described in annex C; and 

- the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog 
included the g.3gpp. mid-call feature-capability indicator. 
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1 2.3.2.2 Transfer of the first session 

When the SCC AS appHes the MSC Server assisted mid-call feature for transfer of the first session the SCC AS shall 
select the first session to transfer as follows. 

The first session to transfer is a session in the transferable session set such that: 

1. if one or more confirmed dialog supporting a session with active speech media component exists in the 
transferable session set then: 

select the confirmed dialog supporting a session with the active speech media component which became 
active most recently; and 

2. if no confirmed dialog supporting a session with active speech media component exists in the transferable set but 
one or more confirmed dialogs supporting a session with inactive speech media component exists for the user 
then: 

select the confirmed dialog supporting a session with inactive speech media component that became inactive 
most recently. 

The SCC AS shall send a SIP re-INVITE request towards the remote UE with a new SDP offer, such that: 

1) if a session with the confirmed dialog supporting a session with active speech media component was selected, 
include the media characteristics as received in the SIP INVITE request due to STN-SR, by following the rules 
of3GPPTS 24.229 [2]; and 

2) if a session with the confirmed dialog supporting a session with inactive speech media component was selected 
then included the an SDP offer describing the audio media streams as negotiated in the session with the remote 
UE and: 

if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and 

- if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

Upon receiving the 2xx response to the re-INVITE request the SCC AS shall: 

1) send the SIP 200 (OK) response to the SIP INVITE request due to STN-SR on the target access leg populated 
as follows: 

a) in the SDP answer, use the relevant media parameter of the SDP answer in the received response; and 

b) include the g.3gpp. mid-call feature-capability indicator described in annex C in the Feature-Caps header 
field. 

Upon receiving the SIP ACK request related to the SIP 200 (OK) response to the SIP INVITE request and if: 

1) the session associated with the SIP INVITE request due to STN-SR is related to a subscription as described in 
subclause 7.3.3; and 

2) a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and 
IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the 
SIP INFO request as follows: 

1) include the Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp. mid-call package name; 
and 

2) include application/vnd.3gpp.mid-callH-xml XML body associated with the info package according to 
IETF RFC 6086 [54] and contaning the participants extracted as specified in the subclause 9.1 A of the 
subscription related to the session associated with the SIP INVITE request due to static STN as described in 
subclause 7.3.3. 

Upon receiving the 2xx response to the SIP INFO request or receiving the ACK related to the SIP 200 (OK) response to 
the SIP INVITE request when the SIP INFO request was not sent, the SCC AS shall: 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 93 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

if one more confirmed SIP dialogs supporting a session with speech media component exist in the transferable 
session set transfer the additional second confirmed SIP dialog as described in subclause 12.3.2.3 and then 
continue with the procedures in this subclause; and 

if no more confirmed SIP dialog supporting a session with speech media component exist in the transferable 
session set but SCC AS support the PS to CS access transfer of a call in alerting phase feature and the conditions 
in the subclause 12.3.4.1 are fulfilled, perform the actions in subclause 12.3.4.4 and then continue with the 
procedures in this subclause. 

The SCC AS shall remove non-tranferred audio components and superfluous session as specified in subclause 12.3.8. 

1 2.3.2.3 Transfer of an additional session 

When the SCC AS applies the MSC Server assisted mid-call feature for transfer of the additional session the SCC AS 
shall select the additional session to transfer as a session in the transferable session set such that: 

1 . if more than one confirmed dialog supporting a session exists in the transferable session set, and exactly one 
confirmed dialog supporting a session with active speech media component exists and there is at least one 
remaining confirmed dialog supporting a session with inactive speech media component then: 

select the confirmed dialog supporting a session with inactive speech media component that became inactive 
most recently; and 

2. if more than one confirmed dialog supporting a session with active speech media component exists in the 
transferable session set then: 

select the confirmed dialog supporting a session with the active speech media component which became 
active second most recently; 

When the SCC AS transfers the selected additional session the SCC AS shall: 

A) send a SIP REFER request towards the MSC Server in accordance with the procedures specified in 

3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE 
request due to STN-SR. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the additional transferred session SCC AS URI for PS to CS SRVCC 
and the following URI header fields containing information related to the additional transferred session: 

a. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

b. the Require URI header field populated with the option tag value "tdialog"; 

c. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted- 
Identity provided by the remote UE during the session establishment; 

d. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user 
identity of the SC UE provided during the session establishment; 

e. the Content-Type header field with "application/sdp"; and 

f. the "body" URI header field populated with an SDP body describing the media streams as negotiated in 
the session with the remote UE and: 

if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and 

if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

4. the Content-Type header field with the value set to MIME type as specified in the subclause D.1.3; 

5. a XML body compliant to the XML schema specified in the subclause D. 1 .2; 
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6. if: 

a. the session associated with the SIP INVITE request due to STN-SR, is not related to any subscription as 
described in subclause 7.3.3; 

b. the additional transferred session is related to a subscription as described in subclause 7.3.3; and 

c. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the 
SC UE within the related subscription; 

then sec AS shall populate the XML body with the participants extracted as specified in the subclause 9.1 A 
of the subscription related to the additional transferred session as specified in subclause 7.3.3; and 

7. if: 

a. sec AS supports CS to PS SRVCC; 

b. the SIP INVITE request due to STN-SR contains Accept header field with application/vnd.3gpp.srvcc- 
ext+xml MIME type; 

c. a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) 
is associated with the C-MSISDN in the P-Asserted-Identity header field of the SIP INVITE request due 
to STN-SR; 

d. a binding of a contact address exists for the private user identity of the UE: 

i) where the g.3gpp.cs2ps-srvcc media feature tag is associated with the contact address of the UE; and 

ii) such that SIP REGISTER request which registered the binding contained a Feature-Caps header field 
with the g.3gpp.atcf feature-capability indicator and with g.3gpp.cs2ps-srvcc feature-capability 
indicator; 

e. the CS to PS SRVCC capability indication is indicated for the private user identity of the UE; and 

f. the private user identity of the UE has the CS to PS SRVCC allowed indication in the subscription data; 
then: 

a. a MIME body of application/vnd.3gpp.srvcc-extH-xml MIME type: 

i) containing ATU management URI of the ATCF serving the SC UE; 

NOTE 2: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature- 
capability indicator included in a Feature-Caps header field of the SIP REGISTER request, which 
registered the binding for the private user identity of the UE. 

ii) containing C-MSISDN; and. 

iii) not indicating that information relate to a registration of MSC server with IMS. 

When the SCC AS receives the SIP INVITE request transferring additional session for PS to CS SRVCC, the SCC AS 
shall: 

1) associate the SIP INVITE request transferring additional session for PS to CS SRVCC with a previously 
established SIP dialog i.e. identify the source access leg; 

NOTE 3: The SIP dialog on the source access leg is identified by matching the dialog present in the Target-Dialog 
header field (see IETF RFC 4538 [11]) of the SIP INVITE request transferring additional session for PS 
to CS SRVCC with the previously established SIP dialog. 

NOTE 4: By a previously established SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP 
INVITE request has been sent or received. 

2) if the SCC AS is unable to associate the SIP INVITE with a unique previously established SIP dialog, send a SIP 
480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 
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3) if the number of media lines in the target access leg is less than the number of media lines in the source access 
leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 404 
(Not Found) response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; and 

4) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], 
containing the following media information: 

A) the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS 
SRVCC for media streams whose port is not set to zero; and 

B) for the media streams in the SIP INVITE request transferring additional session for PS to CS SRVCC whose 
port is set to zero, include the corresponding media characteristics of those streams from the source access 
leg. 

Upon receiving the 2xx response to the re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP 
INVITE request transferring additional session for PS to CS SRVCC on the target access leg populated as follows: 

1) use the relevant media parameter of the SDP answer in the received response; and 

2) include the g.3gpp. mid-call feature-capability indicator as described in annex C in the Feature-Caps header field. 

1 2.3.3 SCC AS procedures for PS to CS SRVCC, abnormal case 

1 2.3.3.1 PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to 

CS domain for ongoing session 

When the SCC AS receives a SIP re-INVITE request containing Reason header field containing protocol "SIP" and 
reason parameter "cause" with value "487" on 

the original source access leg; or 

the original source access leg of the additional transferred session if the SCC AS applies the MSC Server 
assisted mid-call feature; 

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR and the SIP 
INVITE request due to STN-SR transaction is not yet completed then the SCC AS shall wait until this transaction has 
completed and then continue with the steps described below. 

When the SCC AS receives a SIP re-INVITE request(s) containing protocol "SIP" and reason parameter "cause" with 
value "487" after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR, then 
the SCC AS shall: 

1) not release the original access leg once the expiration of the timer described in subclause 12.3.8; and 

2) treat the SIP re-INVITE request(s) as per procedures for removing and adding media as described in 
subclause 13.3.1. 

NOTE: The SCC AS assigns an operator specific timer to delay the release of the Source Access Leg for PS to 
CS SRVCC access transfer. 

When the SCC AS receives a SIP response to the SIP re-INVITE request indicating success in removing all media 
components from a dialog that was created due to the SIP INVITE request due to STN-SR then the SCC AS shall send 
a SIP BYE request on this dialog, by following the rules of 3GPP TS 24.229 [2]. 

1 2.3.3.1 A PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to 
CS domain for session in early dialog state 

If the SCC AS applies the procedures for access transfer for calls in alerting phase (as specified in subclause 12.3.4), 
then when the SCC AS receives a SIP UPDATE request containing Reason header field containing protocol "SIP" and 
reason parameter "cause" with value "487" on: 
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the original source access leg; or 

the original source access leg of the additional transferred session if the SCC AS applies the MSC Server 
assisted mid-call feature; 

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR for a session which 
is still in early dialog state the SCC AS shall: 

1) not release the original access leg after the expiration of the timer described in subclause 12.3.8; 

2) treat the SIP UPDATE request(s) as per procedures for removing and adding media as described in 
subclause 13.3.1; and 

When the SCC AS receives a SIP 200 (OK) response to the SIP UPDATE request, then the SCC AS shall send a SIP 
480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR. 

If the SCC AS has received a SIP 200 (OK) response from the SC UE prior to receiving the SIP UPDATE request from 
the SC UE, then on receipt of the SIP 200 (OK) response to the SIP UPDATE request sent to the remote UE, the SCC 
AS shall send a SIP 200 (OK) response to the remote UE. Upon receiving the SIP ACK request from the remote UE, 
the SCC AS shall send a SIP ACK request to the SC UE. 

1 2.3.3.2 P-CSCF releasing the source access leg during PS to CS SRVCC 

When SCC AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 
503 (Service Unavailable) response code then: 

if the SCC AS receives an initial SIP INVITE request on the Target Access Leg associated with the established 
dialog on the Source Access Leg, within a time defined by the operator policy after the SIP BYE request 
reception, then the SCC AS shall not initiate release of the Remote Leg; and 

if the SCC AS does not receive an initial SIP INVITE request on the Target Access Leg associated with the 
established dialog on the Source Access Leg, within a time defined by the operator policy after the SIP BYE 
request reception then the SCC AS shall initiate release of the Remote Leg. 

NOTE: 8 seconds is an appropriate value for the operator policy. 

1 2.3.3.3 P-CSCF releasing the source access leg when call is in alerting phase 

The procedures specified in subclause 10.3.6 apply. 

1 2.3.4 SCC AS procedures for PS to CS access transfer when call is in 
alerting phase 

12.3.4.1 General 

The SCC AS shall apply the procedures for access transfer for calls in alerting phase as described in subclauses 12.3.4.2 
or 12.3.4.3 if: 

NOTE 1 : The transferable session can contain early dialogs supporting active speech media and video media 

components if the transferable session set was created due to vSRVCC otherwise the transferable session 
set can only contain early dialogs supporting active speech media component. 

1 . the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the 
g.3gpp.srvcc-alerting media feature tag as specified in annex C; and 

2. one of the following is true: 

A. there are one or more dialogs supporting a session with active speech media component or active speech 
media and video media components existing for the served user identified in the transferable set in the P- 
Asserted-Identity header field such that: 

a. all dialogs are early dialogs created by the same SIP INVITE request; 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 97 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

b. SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs; 

c. the Contact header field provided by the SC UE includes the g.3gpp.srvcc-alerting media feature tag as 
described in annex C; and 

d. the Feature-Caps header field provided by the SCC AS towards the SC UE includes the g.3gpp.srvcc- 
alerting feature-capability indicator as described in annex C; or 

B. there are several dialogs supporting sessions with speech media component for the served user identified in 
the P-Asserted-ldentity header field such that: 

a. there are one or more early dialogs created by the same SIP INVITE request and the remaining dialogs 
are confirmed dialogs; 

b. SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs; 

c. all the confirmed dialogs support sessions with inactive speech media component; 

d. SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2; 

e. the Contact header field provided by the SC UE at the establishment of the early dialog(s) included the 
g.3gpp.srvcc-alerting media feature tag; and 

f. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of the 
early dialog(s) includes the g.3gpp.srvcc-alerting feature-capability indicator. 

The SCC AS shall apply the procedures described in subclauses 12.3.4.4 if: 

1 . the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the 
g.3gpp.srvcc-alerting media feature tag; 

2. void; 

3. void; and 

4. one of the following is true: 

A. two or more dialogs supporting sessions with speech media component exist for the served user in the 
transferable set such that: 

a. the Contact header fields provided by the SC UE at the establishment of sessions included the 
g.3gpp.srvcc-alerting media feature tag; 

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of 
sessions included the g.3gpp.srvcc-alerting feature-capability indicator; 

c. one dialog is a confirmed dialog with active speech media component and the remaining dialog(s) are 
early dialog(s) with active speech media component created by the same SIP INVITE request; and 

d. SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs; or 

B. two or more dialogs supporting sessions with speech media component exist for the served user identified in 
the transferable session set such that: 

a. the Contact header fields provided by the SC UE at the establishment of sessions included the 
g.3gpp.srvcc-alerting media feature tag; 

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of 
sessions included the g.3gpp.srvcc-alerting feature-capability indicator; 

c. one dialog is a confirmed dialog with inactive speech media component and the remaining dialog(s) are 
early dialog(s) with active speech media component created by the same SIP INVITE request; 

d. SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs; 
and 

e. the SCC AS also applies the MSC server assisted mid-call feature as described in subclause 12.3.2. 
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C. two or more dialogs supporting the sessions with speech media component exist for the served user identified 
in the transferable session set such that: 

a. the Contact header fields provided by the SC UE at the establishment of the sessions included the 
gjgpp.srvcc-alerting media feature tag; 

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of 
sessions included the g.3gpp.srvcc-alerting feature-capability indicator; 

c. one dialog is a confirmed dialog with active speech media component, there are one or more dialogs that 
are confirmed dialogs with inactive speech media component and the remaining dialog(s) are early 
dialog(s) with active speech media component created by the same SIP INVITE request; 

d. SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs; 
and 

e. the SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2. 

1 2.3.4.2 SCC AS procedures for PS to CS access transfer for terminating call in 
alerting phase using PS to CS SRVCC procedure 

When the session in the transferable session set is a terminating call in alerting phase the SCC AS shall associate the 
SIP INVITE request with the early dialog related to the terminating session in the transferable session set. 

If the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech 
media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall send a 
SIP 183 (Session Progresss) response to the SIP INVITE request due to STN-SR containing the SDP sent by the SCC 
AS in the source access leg of the session being transferred. 

If the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different with the speech 
media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall 
update the remote leg by sending a SIP UPDATE request towards the remote UE using the existing established dialog 
according as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer 
received in the SIP INVITE request due to STN-SR. 

Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS shall send a 
SIP 183 (Session Progress) response in response to the SIP INVITE request due to STN-SR towards the MSC server. 
The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with 
the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request. 

Upon receiving the SIP PRACK request from the target access leg, the SCC AS shall send a SIP INFO request towards 
the MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE 
request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows: 

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info 
package name; and 

2. include an application/vnd. 3gpp.state-and-event-info H-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 with the state- 
info XML element containing "early" and the direction XML element containing "receiver". 

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info 
package name and an application/vnd. 3gpp.state-and-e vent-info H-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 from the MSC Server 
with the event XML element containing "call-accepted", the SCC AS shall send as specified in 3GPP TS 24.229 [2]: 

1) a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE indicating that the 
called party has answered the call; and 

2) a SIP 200 (OK) response to the SIP INVITE request due to STN-SR towards the MSC server to indicate the 
successful access transfer. 

The SCC AS shall remove non-tranferred audio and video media components and superfluous session as specified in 
subclause 12.3.8. 
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1 2.3.4.3 sec AS procedures for PS to CS access transfer for originating call in 
alerting phase using PS to CS SRVCC procedure 

When the session in the transferable session set is an originating call in alerting phase the SCC AS shall associate the 
SIP INVITE request due to STN-SR with an early dialog or early dialogs related to the originating call. 

I f there is only one early dialog related to the originating call in alerting phase available for the served user and if the 
speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media 
component of the SDP received in the source access leg of the session being transferred, the SCC AS shall send a SIP 
183 (Session Progresss) response to the SIP INVITE request due to STN-SR containing the SDP sent by the SCC AS in 
the source access leg of the session being transferred. If the SIP INVITE request due to STN-SR contains a P-Early- 
Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a 
SIP message in the dialog of the original SIP INVITE request sent to the remote leg, the SCC AS shall populate the SIP 
183 (Session Progress) response to the SIP INVITE request due to STN-SR with a P-Early-Media header field 
containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the original SIP 
INVITE request sent to the remote leg. 

If there is only one early dialog related to the originating call in alerting phase available for the served user and the 
speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different with the speech media 
component of the SDP received in the source access leg of the session being transferred, the SCC AS shall update the 
remote leg by sending a SIP UPDATE request towards the remote UE using the existing early dialog as specified in 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer received in the SIP 
INVITE request due to STN-SR. 

The SCC AS shall discard any SIP Ixx provisional responses or the SIP 200 (OK) response to the initial SIP INVITE 
request received from the remote UE to the MSC server until the SIP 200 (OK) response to the INFO request is 
received from the MSC server (see later steps in this subclause). 

NOTE: SIP Ixx responses sent reliably and the SIP 200 (OK) response to the initial SIP INVITE request will be 
retransmitted by the remote UE if the responses are dropped by the SCC AS. 

Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS shall send a 
SIP 183 (Session Progress) response in response to the SIP INVITE request due to STN-SR towards the MSC server. 
The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with 
the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request. If the SIP INVITE request due to 
STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P- 
Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, the SCC AS shall populate the 
SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with a P-Early-Media header field 
containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE 
request. 

If there are more than one early dialogs related to the originating call in alerting phase available for the served user due 
to forking as described in 3GPP TS 24.229 [2], the SCC AS shall update the remote legs by sending SIP UPDATE 
requests simultaneously towards every remote UE using the existing early dialogs as specified in 3GPP TS 24.229 [2]. 
The SCC AS shall populate each SIP UPDATE request with the SDP offer received in the SIP INVITE request due to 
STN-SR. Upon receiving each SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS 
shall create a new early dialog by sending a SIP 183 (Session Progress) response in response to the SIP INVITE request 
due to STN-SR towards the MSC server. The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP 
INVITE request due to STN-SR with the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE 
request. If the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" 
parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP 
UPDATE request, the SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due 
to STN-SR with a P-Early-Media header field containing the value of the last P-Early-Media header field received in a 
SIP message in the dialog of the SIP UPDATE request. 

Upon receiving the first SIP PRACK request from the target access leg, the SCC AS shall send a SIP INFO request 
towards the MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP 
INVITE request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows: 

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info 
package name; and 
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2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to 
IETF RFC 6086 [54] and containing a XML body compliant to the XML schema specified in the annex D.2 with 
the state-info XML element containing "early" the direction XML element containing "initiator". 

The sec AS shall remove non-tranferred audio and video media components and superfluous sessions as specified in 
subclause 12.3.8. 

1 2.3.4.4 sec AS procedures for PS to CS access transfer of waiting call 

In order to transfer waiting call, the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], 
IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request due to STN-SR. The 
SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Require header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the additional transferred session SCC AS URI for PS to CS SRVCC, 
where the URI also includes the following header fields containing the information related to the additional 
transferred session: 

A. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier 
of an early dialog supporting session of the SC UE; 

B. the Require header field populated with the option tag value "tdialog"; 

C. the To header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the remote UE during the session establishment; 

D. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the SC UE during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the header field with hname "body" populated with an SDP body describing the media streams as negotiated 
in the session with the remote UE; 

4. application/vnd.3gpp.state-and-event-infoH-xml MIME body with the state-info XML element containing "early" 
and the direction XML element containing: 

A. if terminating call, the "receiver"; and 

B. if originating call, the "initiator"; and 

5. if: 

A. SCC AS supports CS to PS SRVCC; 

B. the SIP INVITE request due to STN-SR contains Accept header field with application/vnd.3gpp.srvcc- 
ext-Hxml MIME type; 

C. a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) is 
associated with the C-MSISDN in the P-Asserted-Identity header field of the SIP INVITE request due to 
STN-SR; 

D. a binding of a contact address exists for the private user identity of the UE: 

a) where the g.3gpp.cs2ps-srvcc media feature tag is associated with the contact address of the UE; and 

b) such that SIP REGISTER request which registered the binding contained a Feature-Caps header field 
with the g.3gpp.atcf feature-capability indicator and with g.3gpp.cs2ps-srvcc feature-capability indicator; 

E. the CS to PS SRVCC capability indication is indicated for the private user identity of the UE; and 

F. the private user identity of the UE has the CS to PS SRVCC allowed indication in the subscription data; 
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then: 

A. a MIME body of application/vnd.3gpp.srvcc-ext+xml MIME type: 

a) containing ATU management URI of the ATCF serving the SC UE; 

NOTE 2: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature- 
capability indicator included in a Feature-Caps header field of the SIP REGISTER request, which 
registered the binding for the private user identity of the UE. 

b) containing C-MSISDN; and 

c) not indicating that information relate to a registration of MSC server with IMS. 

When the SCC AS receives the SIP INVITE request transferring additional session for PS to CS SRVCC, the SCC AS 
shall: 

associate the SIP INVITE request transferring additional session for PS to CS SRVCC with an SIP dialog in 
early state i.e. identify the Source Access Leg. 

NOTE 1 : The SIP dialog on the Source Access Leg is identified by matching the dialog ID present in Target-Dialog 
header field (see IETF RFC 4538 [11]) of the SIP INVITE with a dialog in early state. 

NOTE 2: By a SIP dialog in early state, it is meant an early SIP dialog which has been created by a provisional 
response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or 
received; 

if the SCC AS is unable to associate the SIP INVITE with a unique dialog in early state, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, send a 
SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining 

steps; 

send a SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created 
by the same INVITE request as the Source Access Leg. The SCC AS shall populate the SIP UPDATE request(s) 
with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media 
information: 

a) the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS 
SRVCC received on the Target Access Leg for media streams whose port is not set to zero; and 

b) for the media streams in the SIP INVITE request transferring additional session for PS to CS SRVCC whose 
port is set to zero, include the corresponding media characteristics of those streams from the Source Access 
Leg. 

If the Remote Leg is an early dialog then when receiving SIP 2xx response to the SIP UPDATE request, the SCC AS 
shall send SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS 
SRVCC. The SCC AS shall populate the SIP response as follows: 

1 . if the Remote Leg is an early dialog originated by the remote UE, include a Recv-Info header field containing 
the g.3gpp.state-and-event package name. 

If the Remote Leg is an early dialog originated by the remote UE then when receiving the SIP INFO request inside the 
Target Access Leg containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package according to 

IETF RFC 6086 [54] and with the event XML element containing "call-accepted" to indicate that the called party 
has answered the call; 

then the SCC AS shall: 
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1 . send SIP 200 (OK) response to the SIP INVITE request to the remote UE; and 

2. send SIP 200 (OK) response to the SIP INVITE request over the Target Access Leg. 

1 2.3.5 sec AS procedures for PS to CS access transfer: PS to CS SRVCC 
enhancement using ATCF 

Upon receiving a SIP INVITE request due to ATU-STI for PS to CS SRVCC, the SCC AS shall: 

1) if there is a Target-Dialog header field in the SIP INVITE request: 

A) determine the transferable session set which are all the sessions of the SC UE whose private user identity is 
associated with Correlation MSISDN that is contained in the P-Asserted-Identity header field of the SIP 
INVITE request; 

B) determine the session that is to be transferred which is a session: 

a) in the transferable session set; 

b) is in the confirmed dialog state; and 

c) with active speech media component which has been made active most recently; and 

C) if the session that is to be transferred is for the same dialog as the dialog identifier in the Target-Dialog 
header field in the SIP INVITE request, then perform the procedures described for SIP INVITE request due 
to STN-SR in subclause 12.3.0B with the following differences: 

a) if: 

the SDP offer in the SIP INVITE request contains speech media component only and the speech 
media component of the SDP offer in the SIP INVITE request is the same as the speech media 
component of the SDP negotiated by the ATCF in the session being transferred; or 

the SDP offer in the SIP INVITE request contains speech media component and video media 
component and the speech media component and the video media component of the SDP offer in the 
SIP INVITE request is the same as the speech media component and the video media component of 
the SDP negotiated by the ATCF in the session being transferred; 

then the SCC AS shall: 

i) not send a SIP re-INVITE request towards remote UE; and 

ii) send a SIP 200 (OK) response to the SIP INVITE request containing the SDP negotiated by SCC AS 
towards ATCF in the session being transferred; 

NOTE: handling when it is determined that there is no session to be transferred or when the dialog identifier in 
the Target-Dialog header field in the SIP INVITE request identifies a dialog other than the session being 
transferred is out of scope of this release of this document. 

D) if the session identified by the dialog identifier in the Target-Dialog header field is a session of the SC UE 
whose private user identity is associated with C-MSISDN that is contained in the P-Asserted-Identity header 
field of the SIP INVITE request and: 

1) is in an early dialog state; or 

2) is in a confirmed dialog state and contains inactive speech media component; 
then 

1) if the session is in an early dialog state, perform the procedures described for SIP INVITE requests due to 
STN-SR in subclause 12.3; and 

2) if the session is in a confirmed dialog state and contains inactive speech media component, perform the 
procedures described for SIP INVITE requests due to STN-SR in subclause 12.3.2; 

2) if there is no Target-Dialog header field in the SIP INVITE request: 
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a) perform the procedures described for SIP INVITE requests due to STN-SR in subclause 12. 3. OB. 

1 2.3.6 sec AS procedures for PS to CS access transfer, vSRVCC 

1 2.3.6.0 Detemine the transferable session set 

When the SCC AS receives a SIP INVITE request for audio and video due to STN-SR on the target access leg the SCC 
AS shall determine the transferable session set. 

A session is in the transferable session set when the session: 

1) is a session of the SC UE whose private user identity is associated with the C-MSISDN that is contained in the 
P-Asserted-Identity header field of the SIP INVITE request; and 

2) is a session supporting active speech and video media components. 
The SCC AS shall: 

1) if the conditions in subclause 12.3.6.2 for applying the PS to CS transfer of a call in an alerting phase feature are 
fulfilled, follow the procedures in subclause 12.3.6.2; and 

2) if the conditions in 1) are not satisfied follow the procedure in subclause 12.3.6.1. 

12.3.6.1 General 

When the SCC AS receives a SIP INVITE request for audio and video due to STN-SR on the target access leg the SCC 
AS shall:associate the SIP INVITE request with a session: 

within the transferable session set; 

with active speech and video media components that was most recently made active; and 

the related dialog is in confirmed state. 

If no confirmed dialogs supporting a session with active speech and video media component exists in the transferable 
session set the SCC AS shall: 

1) send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR; and 

2) if the transferable session set contains dialogs supporting sessions with speech media and/or video media 
components: 

a) if the speech media and/or video media components are the only media component in the dialog then release 
the remote leg as specified in 3GPP TS 24.229 [2]; and 

b) if the speech media and/or video media component are not the only media component in the dialog then 
modify the remote leg and remove the speech media component as specified in 3GPP TS 24.229 [2]. 

Editor's Note: [TEIIO] Potential overlap and interaction of the above procedure with abnormal case handling 
requires further study. 

If confirmed dialogs supporting a session with active speech and video media components exist in the transferable 
session set the SCC AS shall send a SIP re-INVITE request towards the remote UE and in a new SDP offer, include the 
media characteristics as received in the SIP INVITE request due to STN-SR, by following the rules of 
3GPPTS 24.229 [2]. 

Upon receiving the 2xx response to the re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP 
INVITE request due to STN-SR on the target access leg using the relevant media parameter of the SDP answer in the 
received response, by following the rules of 3GPP TS 24.229 [2]. 

The SCC AS shall remove non-tranferred audio media and video media components and superfluous session as 
specified in subclause 12.3.8. 



ETSI 



3GPP TS 24.237 version 1 1 .6.0 Release 11 1 04 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

12.3.6.2 sec AS procedures for PS to CS access transfer when call is in alerting 
phase, vSRVCC 

The sec AS shall apply the procedures for access transfer for calls in alerting phase in subclauses 12.3.4.2 and 12.3.4.3 
according to the conditions specified in subclause 12.3.4.1 with the following differences: 

- the sec AS receives a SIP INVITE request for audio and video due to STN-SR instead of a SIP INVITE for 
STN-SR; and 

one or more early dialogs contain both speech and video media components. 

1 2.3.6.3 sec AS procedures for PS to CS access transfer: vSRVCC enhancement 
using ATCF 

The sec AS shall follow the procedures in subclause 12.3.5 with the following difference: 

instead of performing the procedures for SIP INVITE request due to STN-SR in subclause 12.3.1, the SCC AS 
performs the procedures for SIP INVITE request for audio and video due to STN-SR in subclause 12.3.6. 

1 2.3.6.4 SCC AS procedures for vSR-VCC, abnormal case 

The SCC AS shall follow the procedures in subclause 12.3.3 with the following difference: 

access transfer was triggered by the SCC AS receiving a SIP INVITE request for audio and video due to STN- 
SR instead of a SIP INVITE for STN-SR. 

1 2.3.7 SCC AS procedures for handling of SIP OPTIONS request 

When the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in the 
P-Asserted-Identity header field that the session that was most recently made active is a session with active speech and 
video media components, the SCC AS shall send a 200 (OK) response to the SIP OPTIONS request with an SDP body 
containing "m=" lines for audio and video. 

When the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in the 
P-Asserted-Identity header field that the session that was most recently made active is a session with an active speech 
media component but not an active video media component, the SCC AS shall send a 200 (OK) response to the SIP 
OPTIONS request with an SDP body containing an "m=" line for audio but not video. 

If the SCC AS supports the MSC server assisted mid-call feature and: 

has received the g.3gpp.mid-call media feature tag as described in annex C is included in the Contact header 
field of the SIP INVITE request due to originating filter criteria (as described in subclause 7); or 

has received the g.3gpp. mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP 
INVITE request due to terminating filter criteria (as described in subclause 8) 

then when the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in 
the P-Asserted-Identity header field that there are no sessions with an active speech media component, but there are 
sessions that contain an inactive speech media component, the SCC AS shall send a 200 (OK) response to the SIP 
OPTIONS request with an SDP body containing an "m=" line for audio. 

NOTE: If the session that is most recently made inactive contains inactive speech and video media components, 
the SCC AS only returns the "m=" line for audio and not for video. 

12.3.8 Removal of non-transferred audio media components and 
superfluous sessions 

Upon receiving the SIP ACK request from target access leg, and after an operator specific timer has expired, the SCC 
AS shall: 

1) for each session where no in-dialog request has been received in the source access leg of the session with 
transferred media component(s) within the operator defined time: 
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a) if the session is a session with an active or inactive media component, send a SIP BYE request toward the S- 
CSCF for sending to the served SC UE; 

b) if the session is an early dialog on originating side send a SIP 404 (Not Found) response; and 

c) if the session is an early dialog on terminating side send a SIP CANCEL request; and 

NOTE 1 : The SC UE will receive the SIP request or response only if the SC UE is using Gm after the PS-CS access 
transfer is completed. 

NOTE 2: Delaying the SIP request or response as described above allows an ICS UE to add Gm control if needed 
and an SC UE to reuse the PS dialog in case of SRVCC cancellation. 

2) for each session in the transferable session set for which the speech media component, or the speech media and 
video media component in case of vSRVCC, was not transferred: 

a) if the speech media component or the speech media and video media components is the only media 
component(s) of the session, release remote leg and source access leg; and 

b) if the speech media component or the speech media and video media components are not the only media 
components of the session, modify the remote leg and source access leg and remove the media component(s). 

NOTE 3: In case of INVITE request due to STN-SR video media components are not removed or causing release of 
the remote leg. 

12.3.9 Charging correlation 

The sec AS shall include in Ixx and 2xx responses to the initial INVITE the P-Charging-Vector header field as 
specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the "related-icid" header field parameter containing the 
ICID value of the source access leg in the P-Charging- Vector header field. Additionally, if an "icid-generated-at" header 
field was generated for the source access leg, SCC AS shall include the "related-icid-generated-at" header field 
parameter containing the host name or IP address included in the "icid-generated-at" header field parameter of the 
source access leg. 

1 2.3.1 SCC AS procedures for CS to PS SRVCC 

1 2.3.1 0.1 Distinction of requests 

The SCC AS needs to distinguish the following initial SIP requests: 

1) SIP INVITE requests routed to the SCC AS due to ATU-STI for CS to PS SRVCC in the Request-URL In the 
procedures below, such requests are known as "SIP INVITE requests due to ATU-STI for CS to PS SRVCC". 

2) SIP CANCEL requests cancelHng the SIP INVITE requests due to ATU-STI for CS to PS SRVCC. In the 
procedures below, such requests are known as "SIP CANCEL requests cancelling INVITE due to ATU-STI for 
CS to PS SRVCC". 

3) SIP INVITE requests routed to the SCC AS due to additional transferred session SCC AS URI for CS to PS 
SRVCC in the Request-URL In the procedures below, such requests are known as "SIP INVITE request 
transferring additional session". 

1 2.3.1 0.2 First session transfer 
12.3.10.2.1 General 

If see AS supports CS to PS SRVCC, upon receiving a SIP INVITE request due to ATU-STI for CS to PS SRVCC, 
the SCC AS shall: 

1) determine the transferable dialog set which are all the dialogs (both early and confirmed): 

A) where the g.3gpp.ics media feature tag with value "server" was indicated in Contact header field provided by 
the served user; 
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B) of the served user whose private user identity is associated with C-MSISDN that is contained in the P- 
Asserted-Identity header field of the SIP INVITE request due to ATU-STI for CS to PS SRVCC; and 

C) supporting a session; 

2) if there is a Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC: 

A) determine the dialog being transferred as the dialog with the dialog identifier of the Target-Dialog header 
field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC; and 

B) if the determined dialog being transferred identifies a dialog in the transferable dialog set, continue handling 
the procedures in the subclause 12.3.10.2.2; and 

NOTE: Handling when the dialog identifier in the Target-Dialog header field in the SIP INVITE request due to 
ATU-STI for CS to PS SRVCC identifies a non existing dialog is out of scope of this release of this 
document. 

3) if there is no Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC and if 
the transferable dialog set is not empty: 

A) if sec AS supports the CS to PS SRVCC with the assisted mid-call feature according to operator policy, the 
SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the 
application/vnd.3gpp.mid-callH-xml MIME type and if a dialog: 

a) in the transferable dialog set; 

b) which is a confirmed dialog; and 

c) supporting a session with speech media component; 

exists, then continue handling the procedures in the subclause 12.3.10.2.3 for the dialog and do not handle the 
remaining procedures of this subclause; and 

B) if sec AS supports the CS to PS SRVCC for calls in alerting phase according to operator policy, the SIP 
INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the 
application/vnd.3gpp.state-and-event-infoH-xml MIME type and if a dialog: 

a) in the transferable dialog set; 

b) which is a early dialog; 

c) for which SIP 180 (Ringing) response has been sent or received; and 

d) supporting a session with speech media component; 
exists: 

a) if the dialog was originated by the served user, then continue handling the procedures in the 
subclause 12.3.10.2.4 for the dialog and do not handle the remaining procedures of this subclause; and 

b) if the dialog was originated by the remote UE, then continue handling the procedures in the 
subclause 12.3.10.2.5 for the dialog and do not handle the remaining procedures of this subclause. 

12.3.10.2.2 Transfer of session with active speech media component 

If sec AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall: 

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined 
dialog being transferred; 

2) if the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI for CS to PS 
SRVCC is the same as the speech media component of the SDP negotiated by the ATCF in session supported by 
the determined dialog being transferred: 

A) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with: 
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a) signalling elements described in subclause 6A.4.3; and 

b) the SDP negotiated by SCC AS towards ATCF in the determined dialog being transferred; and 

3) if the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI for CS to PS 

SRVCC differs from the speech media component of the SDP negotiated by the ATCF in the determined dialog 
being transferred: 

A) send SIP re-INVITE request towards the remote UE inside the remote leg of the determined dialog being 
transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with 
the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU- 
STI for CS to PS SRVCC. 

Upon receiving SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall: 

1) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with: 

A) signalling elements as described in subclause 6A.4.3; and 

B) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request. 

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU- 
STI for CS to PS SRVCC, the SCC AS shall: 

1) release the source access leg of the determined dialog being transferred; and 

2) continue handling the procedures in the subclause 12.3.10.3. 

12.3.10.2.3 Transfer of session with inactive speech media component 

If see AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall: 

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined 
dialog being transferred; and 

2) send SIP re-INVITE request towards the remote UE in the remote leg of the determined dialog being transferred 
according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with: 

A) the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU- 
STI for CS to PS SRVCC; and 

B) set the directionality of the speech media component in the SDP offer as used in the session with remote UE. 

Upon receiving SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall send a 
SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with: 

1) signalling elements as described in subclause 6A.4.3; 

2) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request; and 

3) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined dialog being 
transferred. 

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU- 
STI for CS to PS SRVCC, the SCC AS shall: 

1) release the source access leg of the determined dialog being transferred; and 

2) continue handling the procedures in the subclause 12.3.10.3. 

12.3.10.2.4 Transfer of originating alerting session 

If see AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall: 
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1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined 
dialog being transferred; and 

2) send SIP UPDATE request towards the remote UE in the remote leg of the determined dialog being transferred 
according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer 
which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS 
SRVCC. If several early dialogs on the remote leg were established by the SIP INVITE request establishing the 
determined dialog being transferred, the SCC AS shall send SIP UPDATE request to each such early dialog. 

Upon receiving SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall establish 
a new early dialog by sending a SIP 180 (Ringing) response to the SIP INVITE request due to ATU-STI for CS to PS 
SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 180 (Ringing) response with: 

1) signalling elements described in subclause 6A.4.3; 

2) the SDP answer received in the SIP 2xx response to the SIP UPDATE request; 

3) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined dialog being 
transferred; and 

4) if the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains a P-Early-Media header field with the 
"supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the 
dialog of the SIP UPDATE request, a P-Early-Media header field containing the value of the last P-Early-Media 
header field received in a SIP message in the dialog of the SIP UPDATE request. 

Upon receiving SIP PRACK request associated with the SIP 180 (Ringing) response to the SIP INVITE request due to 
ATU-STI for CS to PS SRVCC, the SCC AS shall: 

1) reject the source access leg of the determined dialog being transferred with SIP 404 (Not Found) response; and 

2) continue handling the procedures in the subclause 12.3.10.3. 

12.3.10.2.5 Transfer of terminating alerting session 

If see AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall: 

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined 
dialog being transferred; and 

2) send SIP UPDATE request towards the remote UE in the remote leg of the determined dialog being transferred 
according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer 
which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS 
SRVCC. 

Upon receiving SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall send a 
SIP 183 (Session Progress) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) with: 

1) signalling elements described in subclause 6A.4.3; 

2) the SDP answer received in the SIP 2xx response to the SIP UPDATE request; 

3) the Recv-Info header field with the 3gpp.state-and-event info package name; and 

4) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined dialog being 
transferred. 

Upon receiving the SIP PRACK request from the SC UE associated with the SIP 183 (Session Progress) response to the 
SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall: 

1) send a SIP INFO request towards the SC UE as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the 
dialog created by SIP INVITE request due to ATU-STI for CS to PS SRVCC. The SCC AS shall populate the 
SIP INFO request as follows: 
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A) include the Info-Package header field with 3gpp.state-and-event info package name; and 

B) include an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 with the 
state-info XML element containing "early" and the direction XML element containing "receiver"; and 

2) cancel the source access leg of the determined dialog being transferred. 

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info 
package name and an application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the annex D.2 from the SC UE with 
the event XML element containing "call-accepted", the SCC AS shall: 

1) send a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE as specified in 
3GPPTS 24.229 [2]; and 

2) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC as specified in 
3GPP TS 24.229 [2] populated as described in subclause 6A.4.3. 

Upon receiving the SIP CANCEL request cancelling SIP INVITE request due to ATU-STI for CS to PS SRVCC, the 
SCC AS shall: 

1) send a SIP 200 (OK) response to the SIP CANCEL request; 

2) send a SIP response to the SIP INVITE request received earlier from the remote UE as specified in 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP response with: 

A) if the SIP CANCEL request contains a Reason header field with protocol "SIP", then status code and reason 
text from the Reason header field of the SIP CANCEL request; and 

B) if the SIP CANCEL request does not contain a Reason header field with protocol "SIP", then 486 (Busy) 
status code and reason text; and 

3) send a SIP 487 (Request Terminated) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC 
as specified in 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request on the target access leg of the determined dialog being transferred, the SCC AS 
shall cancel the source access leg of the determined dialog being transferred. 

1 2.3.1 0.3 Additional session transfer 

12.3.10.3.1 General 

If see AS supports CS to PS SRVCC, if SCC AS supports the CS to PS SRVCC with the assisted mid-call feature 
according to operator policy and if the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept 
header field containing the application/vnd.3gpp.mid-callH-xml MIME type then for each dialog: 

1) in the transferable dialog set; 

2) which is a confirmed dialog; 

3) supporting a session with speech media component; and 

4) other than the dialog of the source access leg associated with the SIP INVITE request due to ATU-STI for CS to 
PS SRVCC; 

the SCC AS shall perform the procedures in subclause 12.3.10.3.2. 

If SCC AS supports the CS to PS SRVCC for calls in alerting phase according to operator policy and if the SIP INVITE 
request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the 
application/vnd.3gpp.state-and-event-infoH-xml MIME type then for each dialog: 

i) in the transferable dialog set; 

ii) which is a early dialog; 
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ii) for which SIP 180 (Ringing) response has been sent or received; 

iv) supporting a session with speech media component; and 

v) other than the dialog of the source access leg associated with the SIP INVITE request due to ATU-STl for CS to 
PS SRVCC; 

the sec AS shall perform the procedures in subclause 12.3.10.3.2. 

If transfer of any dialog in the transferable dialog set has not been initiated, the SCC AS shall continue handling the 
procedures in the subclause 12.3.10.4. 

12.3.10.3.2 Additional session transfer initiation 

If see AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall 
send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the 
dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP REFER request as 
follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Require header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the additional transferred session SCC AS URI for CS to PS SRVCC, 
where the URI also includes the following header fields containing the information related to the determined 
dialog being transferred: 

A. the Target-Dialog header field populated as specified in IETF RFC 4538 [1 1], containing the dialog identifier 
of the determined dialog being transferred; 

B. the Require header field populated with the option tag value "tdialog"; 

C. if the remote UE of the remote leg of the determined dialog being transferred did not request privacy then the 
To URI header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the remote UE during the session establishment; 

D. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the SC UE during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the header field with hname "body" populated with an SDP body describing the media streams as negotiated 
in the session with the remote UE; and 

4. if the determined dialog being transferred is a confirmed dialog, an application/vnd.3gpp.mid-callH-xml MIME 
body; and 

5. if the determined dialog being transferred is an early dialog: 

A. application/vnd.3gpp.state-and-event-infoH-xml MIME body with the state-info XML element containing 
"early" and the direction XML element containing: 

a. if terminating call, the "receiver"; and 

b. if originating call, the "initiator". 

Upon receiving the SIP INVITE request transferring additional session, the SCC AS shall: 

1) if the dialog identifier in the Target-Dialog header field of the SIP INVITE request identifies a dialog: 

A) where the asserted identity of the participating served user belongs to the same subscription as the asserted 
identity of the sender of the SIP INVITE request: and 

B) supporting a session with speech media component: 
then: 
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A) determine the additional dialog being transferred as the dialog with the dialog identifier of the Target-Dialog 
header field in the SIP INVITE request transferring additional session; 

B) associate the SIP INVITE request transferring additional session with the remote leg of the determined 
additional dialog being transferred; 

C) if the dialog is a confirmed dialog, continue handling the procedures in the subclause 12.3.10.3.3; 

D) if the dialog is an early dialog established by served user, continue handling the procedures in the subclause 
12.3.10.3.4; and 

E) if the dialog is an early dialog established by remote UE, continue handling the procedures in the subclause 
12.3.10.3.5. 

If receiving the SIP 3xx response, 4xx response or 6xx response to the SIP REFER request or if the SIP INVITE request 
transferring additional session is not received within operator defined time after the SIP REFER request sending, the 
sec AS shall release, cancel or reject the remote leg, the source access leg and the target access leg of the determined 
dialog being transferred. 

12.3.10.3.3 Transfer of session with inactive speech media component 

If sec AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC 
AS shall: 

1) send SIP re-INVITE request towards the remote UE in the remote leg of the determined additional dialog being 
transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the 
SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional 
session. 

Upon receiving SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall: 

1) send a SIP 200 (OK) response to the SIP INVITE request transferring additional session according to 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with: 

A) signalling elements described in subclause 6A.4.3; 

B) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request; and 

C) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined additional 
dialog being transferred. 

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU- 
STI for CS to PS SRVCC, the SCC AS shall: 

1) release the source access leg of the determined dialog being transferred; and 

2) continue handling the procedures in the subclause 12.3.10.4. 

12.3.10.3.4 Transfer of originating alerting session 

If see AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC 
AS shall: 

1) send SIP UPDATE request towards the remote UE in the remote leg of the determined additional dialog being 
transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the 
SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional 
session. If several early dialogs on the remote leg were established by the SIP INVITE request establishing the 
determined additional dialog being transferred, the SCC AS shall send SIP UPDATE request to each such early 
dialog. 

Upon receiving SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall: 
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1) establish a new early dialog by sending a SIP 180 (Ringing) response to the SIP INVITE request transferring 
additional session according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 180 (Ringing) response 
with: 

A) signalling elements described in subclause 6A.4.3; 

B) the SDP answer received in the SIP 2xx response to the SIP UPDATE request; 

C) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined additional 
dialog being transferred; and 

D) if the SIP INVITE request transferring additional session contains a P-Early-Media header field with the 
"supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the 
dialog of the SIP UPDATE request, a P-Early-Media header field containing the value of the last P-Early- 
Media header field received in a SIP message in the dialog of the SIP UPDATE request. 

Upon receiving SIP PRACK request associated with the SIP 180 (Ringing) response to the SIP INVITE request due to 
ATU-STI for CS to PS SRVCC, the SCC AS shall: 

1) reject the source access leg of the determined dialog being transferred with SIP 404 (Not Found) response; and 

2) continue handling the procedures in the subclause 12.3.10.4. 

12.3.10.3.5 Transfer of terminating alerting session 

If see AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC 
AS shall: 

1) send SIP UPDATE request towards the remote UE in the remote leg of the determined additional dialog being 
transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the 
SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional 
session. 

Upon receiving SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall: 

1) send a SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session according 
to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) with: 

A) signalling elements described in subclause 6A.4.3; 

B) the SDP answer received in the SIP 2xx response to the SIP UPDATE request; and 

C) the Recv-Info header field with the 3gpp.state-and-event info package name; and 

D) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the source access leg of the determined additional 
dialog being transferred. 

Upon receiving the SIP PRACK request from the SC UE associated with the SIP 183 (Session Progress) response to the 
SIP INVITE request transferring additional session, the SCC AS shall cancel the source access leg of the determined 
dialog being transferred. 

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info 
package name and an application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 from the MSC 
server with the event XML element containing "call-accepted", the SCC AS shall: 

1) send a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE as specified in 
3GPPTS 24.229 [2]; and 

2) send a SIP 200 (OK) response to the SIP INVITE request transferring additional session as specified in 
3GPP TS 24.229 [2] populated as described in subclause 6A.4.3. 
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Upon receiving the SIP CANCEL request cancelling SIP INVITE request transferring additional session, if the SIP 
CANCEL request is acceptable for the SCC AS, in addition to sending a 2xx response to the SIP CANCEL request, the 
sec AS shall: 

1) send a SIP response to the SIP INVITE request received from the remote UE as specified in 
3GPP TS 24.229 [2]. The SCC AS shall populate the SIP response with: 

A) if the SIP CANCEL request contains a Reason header field with protocol "SIP", then status code and reason 
text from the Reason header field of the the SIP CANCEL request; and 

B) if the SIP CANCEL request does not contain a Reason header field with protocol "SIP", then 486 (Busy) 
status code and reason text; and 

2) send a SIP 487 (Request Terminated) response to the SIP INVITE request transferring additional session as 
specified in 3GPP TS 24.229 [2]. 

1 2.3.1 0.4 Removal of non-transferred sessions 

If see AS supports CS to PS SRVCC, in order to remove non-transferred sessions, the SCC AS shall: 

1) for each session in the transferable session set for which the speech media component was not transferred: 

a) release, reject or cancel the source access leg; 

b) if the speech media component is the only media component(s) of the session, release, reject or cancel the 
remote leg; and 

c) if the speech media component is not the only media components of the session, modify the session and 
remove the speech media component from the remote leg(s). 

1 2.4 MSC server enhanced for ICS 

1 2.4.0 MSC server enhanced for ICS supporting PS to CS SRVCC 

When an MSC server enhanced for ICS supporting SRVCC receives an indication for a PS to CS SRVCC session 
transfer as described in 3GPP TS 23.216 [49], then the MSC server enhanced for ICS shall initiate a SIP INVITE 
request and shall: 

1) set the Request-URI to the STN-SR for the session with speech media component to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the contact address of the MSC server; 

4) include an SDP offer containing only a speech media component; 

5) if SRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a Allocation/Retention 
priority (ARP) indication is received (as described in 3GPP TS 29.280 [71]), then include an authorised 
Resource-Priority header field; 

NOTE 1 : An MSC server enhanced for ICS will use local configuration to map the received ARP value to 
appropriate values for the authorised Resource-Priority header field. 

6) if the MSC server supports the MSC server assisted mid-call feature: 

A) insert the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

B) insert the Accept header field containing the MIME type as specified in subclause D.1.3; 

C) include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 

D) insert the Recv-Info header field containing the g.3gpp. mid-call package name; 

7) if the MSC server enhanced for ICS supports PS to CS access transfer for alerting calls, then include: 
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A) an Accept header field containing the MIME type appUcation/vnd.3gpp.state-and-event-info+xml as 
specified in subclause D.2.3; 

B) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; 

C) a Recv-Info header field containing the g.3gpp.state-and-event package name; and 

D) a P-Early-Media header field containing the "supported" parameter; and 
8) if the MSC server supports CS to PS SRVCC: 

A) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name; 

B) the Accept header field containing application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" 
parameter indicating ability to receive "event-type" attribute with the value "2"; and 

C) the Accept header field containing application/vnd.3gpp.srvcc-extH-xml MIME type; and 

D) the gjgpp.ti media feature tag with value as described in subclause C.12 in the Contact header field. 

NOTE 2: An MSC server enhanced for ICS does not apply the ICS procedure described in 3GPP TS 29.292 [18] 
and 3GPP TS 24.292 [4] when sending the SIP INVITE request. 

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, it shall additionally apply the 
procedures defined in subclause 12.4A. 

If the MSC server enhanced for ICS supports the PS to CS access transfer for alerting calls procedures, it shall 
additionally apply the procedures defined in subclause 12.6.3. 

After finishing the access transfer procedures and regardless of if the access transfer was successful or not, the MSC 
server enhanced for ICS shall apply the ICS procedure as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4]. 

12.4.0A MSC server enhanced for ICS procedures for Emergency Session 
Transfer 

The MSC Server enhanced for ICS shall perform the procedures described in subclause 12.6.2 for the MSC server 
enhanced for SRVCC using SIP interface. 

12.4.0B MSC server enhanced for ICS supporting vSRVCC 

When the MSC server enhanced for ICS supporting vSRVCC receives an indication for a PS to CS SRVCC session 
transfer as described in 3GPP TS 23.216 [49], the MSC server enhanced for ICS supporting vSRVCC shall follow the 
procedures in subclause 12.4.0. 

When an MSC server enhanced for ICS supporting vSRVCC receives an indication for a vSRVCC session transfer as 
described in 3GPP TS 23.216 [49], the MSC server enhanced for ICS shall initiate a SIP OPTIONS request and shall: 

1) set the request URI to the STN-SR; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 

4) set the Accept header field to "application/sdp" 

When the MSC server enhanced for ICS supporting vSRVCC receives a 200 (OK) response to the SIP OPTIONS 
request with an SDP body that contains "m=" lines for audio and video, the MSC server enhanced for ICS shall: 

1) initiate a SIP INVITE request and shall: 

a) set the request URI to the STN-SR for the session with speech and video media components to be transferred; 

b) set the P-Asserted-Identity header field to the Correlation MSISDN; 

c) set the Contact header field to the address of the MSC server; 
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d) include an SDP offer only containing a speech media component and a video media component with default 
codecs for speech and video (as specified in 3GPP TS 26.111 [69]). 

e) if the MSC server enhanced for enhanced for ICS supporting vSRVCC supports PS to CS access transfer for 
alerting calls, then include: 

i) an Accept header field containing the MIME type application/vnd.3gpp.state-and-event-info+xml as 
specified in annex D.2.3; 

ii) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; and 

iii) a Recv-Info header field containing the g.3gpp.state-and-event package name; 

f) if vSRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a 
Allocation/Retention priority (ARP) indication is received (as described in 3GPP TS 29.280 [70]), then 
include an authorised Resource-Priority header field; and 

NOTE: An MSC server enhanced for ICS will use local configuration to map the received ARP value to 
appropriate values for the authorised Resource-Priority header field. 

2) if the MSC server enhanced for ICS supporting vSRVCC supports PS to CS access transfer for alerting calls, 
then additionally apply the procedures defined in subclause 12.6.3. 

When an MSC server enhanced for ICS supporting vSRVCC receives a 200 (OK) response to the SIP OPTIONS 
request with an SDP body that contains an "m=" line for audio but not video, the MSC server enhanced for ICS 
supporting vSRVCC shall follow the procedures in subclause 12.4.0. 

12.4.1 Void 

1 2.4.2 MSC server enhanced for ICS supporting CS to PS SRVCC 

12.4.2.1 Distinction of requests 

The MSC server needs to distinguish the following SIP requests: 
1) SIP INFO request: 

A) with Info-Package header field with value g.3gpp.access-transfer-events; and 

B) with application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package 
according to IETF RFC 6086 [54] and indicating the session transfer notification response. 

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer 
notification response". 

12.4.2.2 General 

If the MSC server supports the CS to PS SRVCC, upon receiving HO required for a UE including an indication that the 
HO is for CS to PS as described in 3GPP TS 23.216 [15] or if required by procedures in subclause 12.4.2.5, the MSC 
server shall: 

1) determine the transferable dialog set which are all SIP dialogs: 

A) interworked with the CS calls of the UE; and 

B) supporting a session; and 

2) if the determined transferable dialog set is not empty: 

NOTE: If the determined transferable dialog set is empty, remaining procedures of this subclause are not invoked. 
A) determine the dialog for communication with ATCF as follows: 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 11 116 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

a) if a CS call in Active (NIO) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 
3GPP TS 24.083 [43]) exists, the SIP dialog in the transferable dialog set, which is interworked with the 
CS call in Active (NIO) state (defined in 3GPP TS 24.008 [8]) and Idle auxihary state (defined in 
3GPP TS 24.083 [43]); and 

b) if a CS call in Active (NIO) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 
3GPP TS 24.083 [43]) does not exist, a SIP dialog in the transferable dialog set, which is interworked 
with any CS call; and 

B) send a SIP INFO request according to 3GPP TS 24.229 [2] within the determined dialog for communication 
with ATCF. The MSC server shall populate the SIP INFO request with: 

a) Info-Package header field with value g.3gpp. access-transfer-events; and 

b) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package 
according to IETF RFC 6086 [54] and indicating the session transfer notification request. 

Upon receiving SIP INFO request carrying the session transfer notification response within the determined dialog for 
communication with ATCF, the MSC server shall: 

1) send a SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; 

2) if the application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body indicates that the ATCF does not require 
the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC 
access transfer, continue handling the procedures in the subclause 12.4.2.3; and 

3) if the application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body indicates that the ATCF requires the MSC 
server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer, 
continue handling the procedures in the subclause 12.4.2.4. 

12.4.2.3 Transfer of session without MSC server redirecting the speech media 
component 

If the MSC server supports the CS to PS SRVCC, if the access transfer is prepared according to 3GPP TS 23.216 [15] 
and if the ATGW does not require the MSC server to redirect the speech media component of the session transferred by 
the CS to PS SRVCC access transfer, the MSC server shall: 

1) send a SIP INFO request according to 3GPP TS 24.229 [2] within determined dialog for communication with 
ATCF. The MSC server shall populate the SIP INFO request with: 

A) Info-Package header field with value g.3gpp. access-transfer-events; and 

B) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according 
to IETF RFC 6086 [54] and indicating the session transfer preparation. 

If the MSC server supports the CS to PS SRVCC, if the ATGW does not require the MSC server to redirect the speech 
media component of the session transferred by the CS to PS SRVCC access transfer and if the access transfer is 
cancelled according to 3GPP TS 23.216 [15], the MSC server shall send a SIP INFO request according to 
3GPP TS 24.229 [2] within determined dialog for communication with ATCF. The MSC server shall populate the SIP 
INFO request with: 

1) Info-Package header field with value g.3gpp. access-transfer-events; and 

2) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according to 
IETF RFC 6086 [54] and indicating the session transfer cancellation. 

12.4.2.4 Transfer of session with MSC server redirecting the speech media 
component 

When the ATGW requires the MSC server to redirect the speech media component of the session transferred by the CS 
to PS SRVCC access transfer, the MSC server shall: 

1) send a SIP INVITE request according to 3GPP TS 24.229 [2]. The MSC server shall populate the SIP INVITE 
request with: 
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A) the Request-URI header filed set to the ATCF management URI; 

B) Contact header filed set to the IP address of MSC server; and 

C) SDP body includes the speech media component of the session transferred by the CS to PS SRVCC access 
transfer. 

If the access transfer is prepared according to 3GPP TS 23.216 [15] and after the MSC server redirect the speech media 
component of the session transferred by the CS to PS SRVCC access transfer to the ATGW, the MSC server shall: 

1) send a SIP INFO request according to 3GPP TS 24.229 [2] within dialog for communication with ATCF. The 
MSC server shall populate the SIP INFO request with: 

A) Info-Package header field with value g.3gpp. access-transfer-events; and 

B) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according 
to IETF RFC 6086 [54] and indicating the session transfer preparation. 

If the MSC server supports the CS to PS SRVCC, if the access transfer is cancelled according to 3GPP TS 23.216 [15], 
the MSC server shall send a SIP INFO request according to 3GPP TS 24.229 [2] within determined dialog for 
communication with ATCF. The MSC server shall populate the SIP INFO request with: 

1) Info-Package header field with value g.3gpp. access-transfer-events; and 

2) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according to 
IETF RFC 6086 [54] and indicating the session transfer cancellation. 

12.4.2.5 Abnormal cases 

If the dialog for communication with ATCF is released after receiving HO required for a UE including an indication 
that the HO is for CS to PS as described in 3GPP TS 23.216 [15] and before sending of the CS to PS handover 
command as described in 3GPP TS 23.216 [15], the MSC shall perform the procedures in subclause 12.4.2.2 again. 

12.4A MSC server assisted mid-call feature 

Upon receiving SIP 2xx response to the SIP INVITE request due to STN-SR, the MSC server shall: 

1 . if inactive speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE 
request due to STN-SR, associate the dialog created by the SIP INVITE request due to STN-SR with a CS call in 
the "active" (NIO) state (defined in 3GPP TS 24.008 [8]) and "call held auxiliary" state (defined in 

3GPP TS 24.083 [43]) with transaction identifier and TI flag value as in mobile terminated call; and 

2. if active speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE 
request due to STN-SR, associate the dialog created by the SIP INVITE request due to STN-SR with a CS call as 
described in 3GPP TS 24.008 [8]. 

Upon receiving a SIP INFO request: 

sent inside in the dialog created by the SIP INVITE request due to STN-SR; 

with the Info-Package header field containing the g.3gpp. mid-call package name; and 

with the application/vnd.3gpp.mid-callH-xml MIME body associated with the info package according to 
IETF RFC 6086 [54]; 

and if the SIP INVITE request due to STN-SR established a session with conference focus then the MSC server shall 
associate the participants extracted from the application/vnd.3gpp.mid-callH-xml MIME body with transaction identifiers 
calculated as in the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the 
participants in their order in the list of the extracted participants. 

NOTE 1 : For an MSC server enhanced for PS to CS SRVCC using SIP interface, following access transfer, the 
procedures for the handling of transferred conference participants are implementation dependent. 

Upon receiving a SIP REFER request: 
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1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside a SIP dialog: 

A. created by the SIP INVITE request due to STN-SR; and 

B. where the g.3gpp. mid-call feature-capability indicator as specified in annex C was included in the Feature- 
Caps header field of the SIP 2xx response to the SIP INVITE request due to STN-SR; and 

5. containing a MIME body of MIME type specified in the subclause D.1.3; 
the MSC server shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional session with inactive speech media component in 
accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. If the MSC server is 
enhanced for ICS, the MSC server does not apply the ICS procedure described in 3GPP TS 29.292 [18] and 
3GPP TS 24.292 [4] when sending the SIP INVITE request for transfer of an additional session with inactive 
speech media component. Additionally, the MSC server shall populate the SIP INVITE request for transfer of an 
additional session with inactive speech media component as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request; and 

e. all or subset of payload type numbers and their mapping to codecs and media parameters not conflicting 
with those in the "body" URI header field in the URI in the Refer-To header field of the received SIP 
REFER request; and 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

D. if an authorised Resource-Priority header field was included in the SIP INVITE request due to STN-SR, then 
include an authorised Resource-Priority header field with the same values as used in the SIP INVITE request 
due to STN-SR; and 

E. if the MSC server supports CS to PS SRVCC and the SIP REFER request contains the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME body: 

a) the topmost Route header field with the ATCF management URI received in the 

application/vnd.3gpp.access-transfer-eventsH-xml MIME body of the REFER request and Ir URI 
parameter; 
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b) the Accept header field containing application/vnd.3gpp.access-transfer-events+xml MIME type with the 
"et" parameter indicating abihty to receive "event-type" attribute with the value "2"; 

c) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; and 

d) the application/vnd.3gpp.srvcc-extH-xml MIME body with the <srvcc-ext> root element containing the 
<Setup-info> element containing the CS to PS SRVCC information received in the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME body of the REFER request and indicating the 
"initiator" role of the MSC server in the session set up; and 

e) the g.3gpp.ti media feature tag with value as described in subclause C. 12 in the Contact header field. 
If two sessions are transferred, the MSC server shall: 

1 . associate the SIP INVITE request for transfer of an additional session with inactive speech media component 
with CS call in the "active" (NIO) state (as defined in 3GPP TS 24.008 [8]) and in the "call held auxiliary" state 
(as defined in 3GPP TS 24.083 [43]) with transaction identifier 1 and TI flag value as in mobile terminated call; 
and; 

2. if the SIP INVITE request for transfer of an additional session with inactive speech media component 
established a session with conference focus then associate the participants extracted from the 
application/vnd.3gpp.mid-callH-xml MIME body included in the SIP REFER request with transaction identifiers 
calculated as in the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 1, 2, 3, 4 are assigned to the 
participants in their order in the list of the extracted participants. 

12.5 EATF 

1 2.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality for 
E-SR-VCC: 

1. SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URL In the procedures below, such 
requests are known as "SIP INVITE requests due to E-STN-SR". 

NOTE: The same E-STN-SR is used for all the emergency session access transfers within one PLMN. 

Other initial SIP requests can be dealt with in any manner conformant with 3GPP TS 24.229 [2]. 

When the EATF receives a SIP INVITE request due to E-STN-SR on the Target Access Leg, the EATF shall: 

1. associate the SIP INVITE request due to E-STN-SR with a source access leg, i.e. an existing SIP session 
anchored at the EATF with the instance-id media feature tag provided by the SC UE in the Contact header field 
at session establishment equal to the instance-id media feature tag included in the Contact header field of the 
received SIP INVITE request. If no source access leg exists or if multiple source access legs exist, then the 
EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN- 
SR; and 

2. originate session modification as described in 3GPP TS 24.229 [2] towards the remote UE with a new SDP offer 
with media characteristics as received in the SIP INVITE request due to E-STN-SR. 

Upon receiving the SIP ACK request from the Target Access Leg, the EATF shall release the source access leg as 
described in 3GPP TS 24.229 [2]. 
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1 2.6 MSC server enhanced for SRVCC using SIP interface 

1 2.6.1 Session transfer from IVISC server enhanced for SRVCC using SIP 
interface 

12.6.1 .1 Session transfer from MSC server enhanced for SRVCC using SIP interface 
supporting PS to CS SRVCC 

When an MSC server enhanced for SRVCC using SIP interface and supporting PS to CS SRVCC receives an indication 
for a PS to CS SRVCC session transfer as described in 3GPP TS 23.216 [49], then the MSC server enhanced for 
SRVCC using SIP interface shall initiate a SIP INVITE request and shall: 

1) set the Request URI to the STN-SR for the session with speech media component to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the contact address of the MSC server; 

4) include an SDP offer containing only a speech media component; and 

5) if SRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a Allocation/Retention 
priority (ARP) indication is received (as described in 3GPP TS 29.280 [71]), then include an authorised 
Resource-Priority header field; 

NOTE: An MSC server enhanced for SRVCC using a SIP interface will use local configuration to map the 
received ARP value to appropriate values for the authorised Resource-Priority header field. 

6) if the MSC server supports the MSC server assisted mid-call feature: 

A. insert the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

B. insert the Accept header field containing the MIME type as specified in annex D.1.3; 

C. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 

D. insert the Recv-Info header field containing the g.3gpp. mid-call package name. 

7) if the MSC server enhanced for SRVCC using SIP interface supports PS to CS access transfer for alerting calls, 
then include: 

a) an Accept header field containing the MIME type application/vnd.3gpp.state-and-event-infoH-xml as 
specified in annex D.2.3; 

b) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; 

c) a Recv-Info header field containing the g.3gpp.state-and-event package name; and 

d) a P-Early-Media header field containing the "supported" parameter. 

If the MSC server enhanced for SRVCC using SIP interface supports the MSC server assisted mid-call feature then it 
shall additionally apply the procedures defined in subclause 12.4A. 

If the MSC server enhanced for SRVCC using SIP interface supports PS to CS access transfer for alerting calls then in 
addition to the procedures in this subclause it shall additionally apply the procedures defined in subclause 12.6.3. 

12.6.1 .2 Session transfer from MSC server enhanced for SRVCC using SIP interface 
supporting vSRVCC 

When an MSC server enhanced for SRVCC using SIP interface and supporting vSRVCC receives an indication for a 
vSRVCC session transfer as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP 
interface shall initiate a SIP OPTIONS request and shall: 

1) set the request URI to the STN-SR; 
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2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 

4) set the Accept header field to "application/sdp" 

When an MSC server enhanced for SRVCC using SIP interface and supporting vSRVCC receives a 200 (OK) response 
to the SIP OPTIONS request with an SDP body that contains "m=" lines for audio and video, the MSC server enhanced 
for SRVCC using SIP interface shall: 

1) initiate a SIP INVITE request and shall: 

a) set the request URI to the STN-SR for the session with speech and video media components to be transferred; 

b) set the P-Asserted-Identity header field to the Correlation MSISDN; 

c) set the Contact header field to the address of the MSC server; 

d) include an SDP offer containing only a speech media component and a video media component with default 
codecs for speech and video (as specified in 3GPP TS 26.111 [69]). 

e) if the MSC server enhanced for SRVCC using SIP interface supports PS to CS access transfer for alerting 
calls, then include: 

i) an Accept header field containing the MIME type application/vnd.3gpp.state-and-event-info+xml as 
specified in annex D.2.3; 

ii) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; and 

iii) a Recv-Info header field containing the g.3gpp.state-and-event package name; 

f) if vSRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a 
Allocation/Retention priority (ARP) indication is received (as described in 3GPP TS 29.280 [70]), then 
include an authorised Resource-Priority header field; and 

NOTE: An MSC server enhanced for SRVCC using a SIP interface will use local configuration to map the 
received ARP value to appropriate values for the authorised Resource-Priority header field. 

2) if the MSC server enhanced for SRVCC using SIP interface supports PS to CS access transfer for alerting calls, 
then additionally apply the procedures defined in subclause 12.6.3. 

When an MSC server enhanced for SRVCC using SIP interface and supporting vSRVCC receives a 200 (OK) response 
to the SIP OPTIONS request with an SDP body that contains an "m=" line for audio but not video, the MSC server 
enhanced for SRVCC using SIP interface shall follow the procedures in subclause 12.6.1.1. 

1 2.6.2 Emergency session transfer from MSC server enhanced for SRVCC 
using SIP interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an 
emergency session as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP 
interface shall initiate a SIP INVITE request and shall: 

1) set the request URI to the E-STN-SR for the session with speech media component to be transferred; 

2) include the instance-id feature tag as specified in IETF RFC 5626 [22] with a value based on the IMEI as defined 
in 3GPP TS 23.003 [12] in the Contact header field; 

3) set the P-Asserted-Identity header field to the Correlation MSISDN if one is available; and 

4) include an SDP offer with media which the MSC server wishes to use in the session. 
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1 2.6.3 MSC server enhanced for SRVCC using SIP interface procedures 
for PS to CS access transfer for alerting calls 

Upon receiving a SIP Ixx response with P-Early-Media header field authorizing backward early media, unless the CS- 
MGW has already been through-connected, the MSC server instructs the CS-MGW to through-connect. 

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR: 

1. with the Info-Package header field containing the g.3gpp.state-and-event; and 

2. containing an application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the 
state-info XML element containing "early" and direction XML element containing "initiator"; 

the MSC server enhanced for SRVCC using SIP interface shall enter the "call delivered" (N4) state as specified in 
3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC using SIP interface shall associate this session with 
transaction identifier value and TI flag as described in 3GPP TS 24.008 [8]. 

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR: 

1 . with the Info-Package header field containing the g.3gpp.state-and-event; and 

2. containing an application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the 
state-info XML element containing "early" and direction set to "receiver"; 

and when a related CC CONNECT has not been received, the MSC server enhanced for SRVCC using SIP interface 
shall enter the "call received" (N7) state as specified in 3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC 
using SIP interface will not generate an in-band ring tone towards the calling party. The MSC server enhanced for 
SRVCC using SIP interface shall associate this session with transaction identifier value and TI flag as described in 
3GPP TS 24.008 [8]. If the CS-MGW has already been through-connected, the MSC server instructs the CS-MGW not 
to through-connect. 

Upon receiving a CC CONNECT message when in "call received" (N7) state as specified in 3GPP TS 24.008 [8], the 
MSC server enhanced for SRVCC using SIP interface shall enter the "active" (NIO) state as specified in 
3GPP TS 24.008 [8] and send a SIP INFO request inside the dialog created with the SIP INVITE request due to STN- 
SR for access transfer containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. include application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package according to 
IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the event XML 
element containing "call-accepted" to indicate that the called party has answered the call. 

Upon receiving a CC CONNECT message after having sent the SIP INVITE request due to STN-SR when not yet in 
"call received" (N7) state as specified in 3GPP TS 24.008 [8], the MSC server enhanced for SRVCC using SIP interface 
will store this event. Once a related SIP INFO request inside the associated early dialog: 

1. with the Info-Package header field containing the g.3gpp.state-and-event; and 

2. containing an application/vnd.3gpp.state-and-event-infoH-xml XML body associated with the info package 
according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the 
state-info XML element containing "early" and direction set to "receiver"; 

is received, then 

1. the MSC server enhanced for SRVCC using SIP interface will enter "active" (NIO) state as specified in 
3GPPTS 24.008 [8]; 

2. the MSC server shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to 
STN-SR for access transfer containing: 

a) an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package 
name; and 
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b) include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package 

according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the 
event XML element containing "call-accepted" to indicate that the called party has answered the call. 

NOTE 1 : Procedures in the MSC server enhanced for SRVCC using SIP interface how to store and supervise the 
reception of the INFO request are left implementation specific. 

Upon receiving a SIP REFER request: 

1 . sent inside the dialog created by the SIP INVITE request due to STN-SR; 

2. with the Refer-Sub header field containing "false" value; and 

3. containing application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element 
containing "early"; 

the MSC server shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request transferring the additional transferred session according to 3GPP TS 24.229 [2] and 
IETF RFC 3515 [13]. The MSC server shall populate the SIP INVITE request as follows: 

A. header fields which were included in the URI in the Refer-To header field of the received SIP REFER 
request as specified in IETF RFC 3261 [19] except the header field with hname "body"; 

B. include in the Contact header field the g.3gpp.srvcc-alerting media feature tag; 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the header field with hname "body" in the URI in the 
Refer-To header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the header field with 
hname "body" in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the header field with hname 
"body" in the URI in the Refer-To header field of the received SIP REFER request has port with zero 
value; and 

d. all or subset of payload type numbers and their mapping to codecs and media parameters not conflicting 
with those in the "body" URI header field in the URI in the Refer-To header field of the received SIP 
REFER request; and 

NOTE 2: port can be set to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER 
request has port with nonzero value. 

D. if the MSC server supports CS to PS SRVCC and the SIP REFER request contains the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME body: 

a) the topmost Route header field with the ATCF management URI received in the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME body of the REFER request and Ir URI 
parameter; 

b) the Accept header field containing application/vnd.3gpp.access-transfer-eventsH-xml MIME type with the 
"et" parameter indicating ability to receive "event-type" attribute with the value "2"; 

c) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; and 

d) the application/vnd.3gpp.srvcc-extH-xml MIME body with the <srvcc-ext> root element containing the 
<Setup-info> element containing the CS to PS SRVCC information received in the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME body of the REFER request and indicating the 
"initiator" role of the MSC server in the session set up; and 
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e) the g.3gpp.ti media feature tag with value as described in subclause C. 12 in the Contact header field; 

3. if application/vnd.3gpp.state-and-event-info+xml MIME body contains direction XML element containing 
"initiator", then enter the "call deUvered" (N4) state as specified in 3GPP TS 24.008 [8] for the CS call with 
transaction identifier 1 and TI flag value as in mobile terminated call; and 

4. if application/vnd.3gpp.state-and-event-info+xml MIME body contains direction XML element containing 
"receiver", then enter the "call received" (N7) state as specified in 3GPP TS 24.008 [8] for the CS call with 
transaction identifier 1 and TI flag value as in mobile terminated call. The MSC server will not generate an in- 
band ring tone towards the calling party. 

Upon receiving a CC CONNECT message with transaction identifier 1 and TI flag value as in mobile terminated call 
when in "call received" (N7) state as specified in 3GPP TS 24.008 [8], the MSC server shall send a SIP INFO request 
inside the dialog created by the SIP INVITE request transferring the additional transferred session containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to 
IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the event XML 
element containing "call-accepted" to indicate that the called party has answered the call. 

NOTE 3: When the transfer is complete the MSC server can verify the call state of its peer entity using the 

STATUS ENQUIRY procedure in accordance with procedures in 3GPP TS 24.008 [8] to ensure that SIP 
requests or SIP responses that have been sent between the SC UE and the SCC AS during the handover 
from the PS domain to the CS domain did not result in incompatible call states. If the call states are 
incompatible the transferred session are released. 

When the MSC server is in the "call delivered" (N4) state and when the MSC server receives a SIP 200 (OK) response 
to the SIP INVITE request due to STN-SR the MSC server sends the CC CONNECT message and enters the "active" 
(NIO) state in accordance with 3GPP TS 24.008 [8]. 

When the MSC server is in the "call received" (N7) state and when the MSC server receives a SIP 200 (OK) response to 
the SIP INVITE request due to STN-SR the MSC server sends the CC CONNECT ACK message and enters the 
"active" (NIO) state in accordance with 3GPP TS 24.008 [8]. 

12.7 Access Transfer Control Function (ATCF) 
12.7.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

1) SIP INVITE requests containing the STN-SR allocated to the ATCF in the Request-URI and: 

A) not containing any Route header field; or 

B) containing a URI in the topmost Route header field other than the ATCF URI for originating requests and 
other than the ATCF URI for terminating requests. 

In the procedures below, such requests are known as "SIP INVITE requests due to STN-SR". 

2) initial SIP INVITE requests containing the STI-rSR allocated to the ATCF in the Request-URI and with the 
ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are 
known as "SIP INVITE requests due to STI-rSR". 

3) SIP INVITE requests contaning the ATCF management URI in the Request-URI and: 

not containing Route header field; 

or containing a URI in the topmost Route header field other than the ATCF URI for originating requests and 
other than the ATCF URI for terminating requests. 

In the procdures below, such requests are known as "SIP INVITE requests due to media transfer from MSC 
Server to ATGW". 
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The ATCF needs to distinguish the following SIP in-dialog requests: 

1) SIP INFO request: 

A) with Info-Package header field with value g.3gpp.access-transfer-events; and 

B) with application/vnd.g.3gpp.access-transfer-events+xml MIME body associated with the info package 
according to IETF RFC 6086 [54] and indicating the session transfer notification request. 

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer 
notification request". 

2) SIP INFO request: 

A) with Info-Package header field with value g.3gpp.access-transfer-events; and 

B) with application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package 
according to IETF RFC 6086 [54] and indicating the session transfer preparation. 

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer 
preparation" . 

3) SIP INFO request: 

A) with Info-Package header field with value g.3gpp.access-transfer-events; and 

B) with application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package 
according to IETF RFC 6086 [54] and indicating the session transfer cancellation. 

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer 
cancellation". 

1 2.7.2 ATCF procedures for PS to CS access transfer, PS to CS SRVCC 

12.7.2.1 General 

Upon receiving the SIP INVITE request due to STN-SR, the ATCF shall: 

1) determine the transferable session set which are all the sessions with a speech media component: 

a) associated with C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE 
requests due to STN-SR; and 

b) where during establishment of the session a Feature-Caps header field containing the g.3gpp.srvcc feature- 
capability indicator was received in the initial SIP request or SIP response; and 

NOTE: These sessions potentially include recently released sessions for which the ATCF temporarily retains 
session state according to subclause 12.7.2.3. 

2) determine the session being transferred which is a session: 

a) in the transferable session set; 

b) for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or 
received; and 

c) with active speech media component which has been made active most recently. 

12.7.2.2 Active session transfer 

If a session is in the transferable session set as determined in subclause 12.7.2.1 and the following conditions are true: 

the session is a confirmed dialog with an active speech media component which has been made active most 
recently; 
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the ATGW anchors the media of the session being transferred; and 

if the speech media component of the SDP offer in the SIP INVITE request is the same as the speech media 
component of the SDP negotiated by the ATCF in the session being transferred or if the ATGW can provide 
media transcoding between the speech media component in the received SDP offer and the speech media 
component in the session being transferred; 

the ATCF shall act as B2BUA as described in subclause 5.6 and shall: 

NOTE 1 : At this point, ATCF interacts with ATGW to provide information needed in the procedures below and to 
request ATGW to start forwarding the audio media from the remote UE to the MSC server. The details of 
interaction between ATCF and ATGW are out of scope of this document. 

0) if ATCF supports CS to PS SRVCC: 

a) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) 
containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests 
due to STN-SR; and 

b) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request due 
to STN-SR; 

1) send a SIP 200 (OK) response to the received SIP INVITE request due to STN-SR that contains: 

a) the saved Contact header field of the remote UE as describe in subclause 7.5.2; 

b) the Record-Route header field that contains only the SIP URI pointing to the ATCF; 

c) the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW; and 

d) include the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and 
include the "related-icid" header field parameter containing the ICID value of the source access leg in the P- 
Charging-Vector header field. Additionally, if an "icid-generated-at" header field was generated for the 
source access leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the 
host name or IP address included in the "icid-generated-at" header field parameter of the source access leg; 
and 

e) if ATCF supports CS to PS SRVCC: 

A) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name; 

B) the Accept header fields received in the home leg of the session being transferred by PS to CS SRVCC 
except the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME 
type; and 

C) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and 
values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-eventsH-xml 
MIME type of the Accept header field received in the home leg of the session being transfered by PS to 
CS SRVCC; 

NOTE 2: At this point the ATCF requests the ATGW to start forwarding the audio media from the MSC server to 
the remote UE. The details of interaction between ATCF and ATGW are out of scope of this document. 

2) initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due 
to ATU-STI for PS to CS SRVCC toward the SCC AS populated with: 

a) the SDP offer containing the currently used media with ATGW ports and IP addresses towards the remote 
UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types 
offered in the received SIP INVITE request due to STN-SR; 

b) the Request-URI containing the ATU-STI for PS to CS SRVCC previously received from the SCC AS and 
associated with the session being transferred; and 

c) the Target-Dialog header field with the dialog identifier of the session being transferred; 
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d) the Require header field containing the option tag 'tdialog'; 

e) the Contact header field that contains the contact information received in the SIP INVITE request due to 
STN-SR; 

f) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent the in-dialog requests fi^om the SCC AS; 

NOTE 3: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

g) the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the 
INVITE request due to STN-SR; 

h) all header fields which are included in the INVITE request due to STN-SR and which contain option tag(s); 

i) if the Recv-Info header field is included in the INVITE request due to STN-SR, the Recv-Info header field 
that is the same as the Recv-Info header field received in the INVITE request due to STN-SR except, if the 
ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp. access-transfer- 
events info package name; 

j) if the Accept header field is included in the INVITE request due to STN-SR, the Accept header field that is 
the same as the Accept header field received in the INVITE request due to STN-SR except, if the ATCF 
supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer- 
eventsH-xml MIME type; and 

k) if the ATCF supports the CS to PS SRVCC, if an Accept header field of the SIP INVITE request due to STN- 
SR contains the application/vnd.3gpp.access-transfer-eventsH-xml with the "et" parameter indicating ability to 
receive "event-type" attribute with values additional to the value "2": 

a) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and 

b) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name. 

If a session is in the transferable session set as determined in subclause 12.7.2.1, ATCF does not support CS to PS 
SRVCC and one of the following conditions are true: 

the ATGW does not anchor the media of the session being transferred; or 

if the speech media component of the SDP offer in the SIP INVITE request is not the same as the speech media 
component of the SDP negotiated by the ATCF in the session being transferred and the ATGW can not provide 
media transcoding between the speech media component in the received SDP offer and the speech media 
component in the session being transferred; 

the ATCF shall act as proxy and shall: 

1) replace the Request-URI in the received SIP INVITE request due to STN-SR with the ATU-STI for PS to CS 
SRVCC associated with the session being transferred; 

before forwarding the request. 

If a session being transferred was determined in subclause 12.7.2.1, ATCF supports CS to PS SRVCC and one of the 
following conditions are true: 

the ATGW does not anchor the media of the session being transferred; or 

if the speech media component of the SDP offer in the SIP INVITE request is not the same as the speech media 
component of the SDP negotiated by the ATCF in the session being transferred and the ATGW can not provide 
media transcoding between the speech media component in the received SDP offer and the speech media 
component in the session being transferred; 

the ATCF shall act as B2BUA and shall: 
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1) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) 
containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due 
to STN-SR; 

2) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request due to 
STN-SR; and 

3) send a SIP INVITE request due to ATU-STI for PS to CS SRVCC according to 3GPP TS 24.229 [2]. The ATCF 
shall populate the SIP INVITE request due to ATU-STI for PS to CS SRVCC with: 

A) the Request-URI set to the ATU-STI for PS to CS SRVCC associated with the session being transferred; 

B) all Route header fields of the SIP INVITE request due to STN-SR except the topmost Route header field; 

C) the Record-Route header field containing the SIP URI of the ATCF; 

D) the Recv-Info header fields of the SIP INVITE request due to STN-SR except the Recv-Info header field 
containing the g.3gpp. access-transfer-events info package name; 

E) the Accept header fields of the SIP INVITE request due to STN-SR except the Accept header field 
containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type; 

F) if an Accept header field of the SIP INVITE request due to STN-SR contains the 
application/vnd.3gpp.access-transfer-eventsH-xml with the "et" parameter indicating ability to receive "event- 
type" attribute with values additional to the value "2": 

a) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and 

b) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; 

G) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

a) all MIME bodies of the SIP INVITE request due to STN-SR apart from application/sdp MIME body; and 

b) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 

NOTE 1 : ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

H) if the ATCF decided not to anchor the media according to operator policy as specified in 

3GPPTS 23.237 [9]: 

a) all MIME bodies of the SIP INVITE request due to STN-SR; and 

I) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header field. 

If the ATCF supports CS to PS SRVCC, when the ATCF receives any SIP Ixx or 2xx response to the SIP INVITE 
request due to ATU-STI for PS to CS SRVCC, the ATCF shall: 

1) save the Contact header field included in the SIP response; and 

NOTE 2: If the ATCF subsequently receives an initial INVITE request due to STI-rSR, the ATCF will include the 
saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial INVITE 
request due to STI-rSR. 

2) generate and send a SIP response to the SIP INVITE request due to STN-SR populated with: 

A) the same status code as the received SIP response to the SIP INVITE request due to ATU-STI for PS to CS 
SRVCC; and 

B) the Record-Route header field containing the SIP URI of the ATCF; 

C) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the 
g.3gpp.access-transfer-events info package name; 
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D) if the SIP response is SIP Ixx response: 

a) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" 
parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and 
values, if any, indicated in the "et" parameter of the g.3gpp. access-transfer-events info package name of 
the Recv-Info header field of the received SIP response; and 

E) if the SIP response is SIP 2xx response: 

a) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; 

b) the Accept header fields of the received SIP response except the Accept header field containing the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME type; and 

c) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and 
values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-eventsH-xml 
MIME type of the Accept header field of the received SIP response. 

12.7.2.3 Abnormal procedures 

12.7.2.3.1 P-CSCF releasing the source access leg during PS to CS SRVCC 

When the ATCF receives either: 

1) a SIP BYE request on the Source Access Leg containing a Reason header field containing a SIP 503 (Service 
Unavailable) response code, that is terminating an established dialog or an early dialog on the Source Access 
Leg; 

2) a SIP CANCEL request on the Source Access Leg with the Reason header field containing a SIP 503 (Service 
Unavailable) response code then, that is terminating an early dialog on the Source Access Leg originated by the 
SC UE; or 

3) a SIP 503 (Service Unavailable) response on the Source Access Leg, that is terminating an early dialog on the 
Source Access Leg terminating at the SC UE; 

then: 

the ATCF shall retain session state information and ATGW resources associated with the session until either it 
receives a SIP INVITE request due to STN-SR or an operator determined period elapses. 

NOTE 1: The default value of the operator determined period is 8 seconds. 

NOTE 2: The session remains recognizable for PS to CS SRVCC access transfer as shown in subclause 12.7.2. L 

NOTE 3: The SIP BYE request is forwarded to the SCC AS, which also delays release of the session, as described 
in subclause 12.3.3.2. 

12.7.2.3.2 No transferable session exists 

If the transferable session set determined in subclause 12.7.2.1 does not contain any sessions and the identity in the P- 
Asserted-Identity header field is a C-MSISDN that is not bound to a registration path in the ATCF, the ATCF shall 
respond with a SIP 404 (Not Found) response. 

If the transferable session set determined in subclause 12.7.2.1 does not contain any sessions and if the identity in the P- 
Asserted-Identity header field is a C-MSISDN that is bound to a registration path in the ATCF, the ATCF shall respond 
with a SIP 480 (Temporarily Unavailable) response. 

1 2.7.2.4 Transfer when only held or alerting session exist 

If the transferable session set determined in subclause 12.7.2.1 is not empty and each session in the transferable session 
set: 

1) is in an early dialog state; or 
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2) is in a confirmed dialog state and contains inactive speech media component; 
then the ATCF shall: 

1) if ATCF decides to not anchor media according to local policy and if ATCF does not support CS to PS SRVCC, 
provide the proxy role as specified in 3GPP TS 24.229 [2] and replace the Request-URI in the received SIP 
INVITE request due to STN-SR with ATU-STI for PS to CS SRVCC associated with a session in the 
transferable session set before forwarding the request and do not process the remaining steps; 

2) if ATCF decides to anchor media according to local policy, determine the session to transfer as follows: 

a) if: 

A) one or more confirmed dialogs supporting a session with inactive speech media component exists in the 
transferable session set; 

B) the Feature-Caps header field provided by the SCC AS towards the SC UE includes the g.3gpp.mid-call 
feature-capability indicator as described in annex C; and 

C) the Contact header field provided by the SC UE to the SCC AS includes the g.3gpp.mid-call media 
feature tag (as described in annex C); 

select the confirmed dialog supporting a session with inactive speech media component that became inactive 
most recently; and 

b) if no confirmed dialog supporting a session with inactive speech media component exists in the transferable 
session set but there are one or more dialogs in the transferable session set supporting a session with an active 
speech media component such that: 

all dialogs are early dialogs created by the same SIP INVITE request; 

the Contact header field provided by the SC UE includes the gjgpp.srvcc-alerting media feature tag as 
described in annex C; and 

the Feature-Caps header field provided by the SCC AS towards the SC UE includes the gjgpp.srvcc- 
alerting feature-capability indicator as described in annex C; 

then select any of the early dialogs; 

3) if ATCF supports the CS to PS SRVCC: 

a) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) 
containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests 
due to STN-SR; and 

b) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request due 
to STN-SR; and 

4) provide the role of a B2BUA in accordance with 3GPP TS 24.229 [2] and initiate a new dialog toward the SCC 
AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI toward the SCC AS 
populated with: 

a) if ATCF decides to anchor media according to local policy: 

A) the SDP offer containing the currently used media with ATGW ports and IP addresses towards the remote 
UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media 
types offered in the received SIP INVITE request due to STN-SR; 

B) all MIME bodies of the SIP INVITE request due to STN-SR apart from application/sdp MIME body; 

C) the Request-URI containing the ATU-STI for PS to CS SRVCC previously received from the SCC AS 
and associated with the session being transferred; 

D) the Target-Dialog header field with the dialog identifier of the session being transferred; and 

E) the Require header field containing the option tag "tdialog"; 
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b) if the ATCF supports the CS to PS SRVCC and the ATCF decides not to anchor media according to local 
policy: 

i) all MIME bodies of the SIP INVITE request due to STN-SR; and 

ii) the Request-URI containing the ATU-STI for PS to CS SRVCC associated with a session in the 
transferable session set; 

c) the Contact header field that contains the contact information received in the SIP INVITE request due to 
STN-SR; 

d) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; 

NOTE 1: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

e) the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the 
INVITE request due to STN-SR; 

f) all header fields which are included in the INVITE request due to STN-SR and which contain option tag(s); 

g) if the Recv-Info header field is included in the INVITE request due to STN-SR, the Recv-Info header field 
that is the same as the Recv-Info header field received in the INVITE request due to STN-SR except, if the 
ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp. access-transfer- 
events info package name; 

h) if the Accept header field is included in the INVITE request due to STN-SR, the Accept header field that is 
the same as the Accept header field received in the INVITE request due to STN-SR. except, if the ATCF 
supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer- 
eventsH-xml MIME type; and 

i) if the ATCF supports the CS to PS SRVCC and an Accept header field of the SIP INVITE request due to 
STN-SR contains the application/vnd.3gpp.access-transfer-eventsH-xml with the "et" parameter indicating 
ability to receive "event-type" attribute with values additional to the value "2": 

A) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type with 
the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and 

B) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name. 

Upon receiving an 18x or 2xx response to the SIP INVITE request due to ATU-STI from the SCC AS, the ATCF shall: 

1) if ATCF supports CS to PS SRVCC, save the Contact header field included in the SIP response; and 

NOTE 2: If the ATCF subsequently receives an initial INVITE request due to STI-rSR, the ATCF will include the 
saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial INVITE 
request due to STI-rSR. 

2) generate and send a SIP response to the SIP INVITE request due to STN-SR populated with: 

a) the Record-Route header field with a Record-Route header field that contains only the SIP URI pointing to 
the ATCF; 

b) the same status code as the received SIP response to the SIP INVITE request due to ATU-STI for PS to CS 
SRVCC; and 

c) if ATCF supports CS to PS SRVCC: 

A) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the 
g.3gpp. access-transfer-events info package name; 

B) if the SIP response is SIP Ixx response, the Recv-Info header field containing the g.3gpp. access-transfer- 
events info package name with the "et" parameter indicating ability to receive "event-type" attribute with 
value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the g.3gpp. access- 
transfer-events info package name of the Recv-Info header field of the received SIP response; and 
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C) if the SIP response is SIP 2xx response: 

i) the Recv-Info header field containing the g.3gpp. access-transfer-events info package name; 

ii) the Accept header fields of the received SIP response except the Accept header field containing the 
application/vnd.3gpp.access-transfer-eventsH-xml MIME type; and 

iii) the Accept header field containing the application/vnd.3gpp.access-transfer-eventsH-xml MIME type 
with the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" 
and values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer- 
eventsH-xml MIME type of the Accept header field of the received SIP response. 

1 2.7.3 ATCF procedures for CS to PS SRVCC 

12.7.3.1 General 

If the ATCF supports the CS to PS SRVCC, upon receiving SIP INFO request carrying the session transfer notification 
request, the ATCF shall: 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; 

2) determine the session being transferred as the session supported by the dialog of the SIP INFO request; and 

3) if a SIP 2xx response to the initial INVITE request has been sent in the dialog of the determined session being 
transferred and if the determined session being transferred includes an active speech media component: 

A) if the ATGW anchors the speech media component of the determined session being transferred, continue 
handling the procedures in the subclause 12.7.3.2; and 

B) if the ATGW does not anchor the speech media component of the determined session being transferred, 
continue handling the procedures in the subclause 12.7.3.3; and 

4) if the determined session being transferred does not include an active speech media component, continue 
handling the procedures in the subclause 12.7.3.4. 

12.7.3.2 Transfer of session with active speech media component anchored in ATGW 

If the ATCF supports the CS to PS SRVCC, in order to transfer the determined session being transferred with the 
speech media component anchored in ATGW, the ATCF shall: 

NOTE 1 : At this point, ATCF interacts with ATGW to reserve resources and provide the information needed in the 
procedures below. The details of interaction between ATCF and ATGW are out of scope of this 
document. 

1) for each registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the session of 
the SIP INFO request carrying the session transfer notification request, set: 

A) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1); and 

B) the home leg of the session being transfered by CS to PS SRVCC (see subclause 6A.3.1) to the dialog 
identifier of the home leg of the determined session being transferred; and 

2) send a SIP INFO request within the dialog of the SIP INFO request carrying the session transfer notification 
request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INFO request with: 

A) Info-Package header field with value g.3gpp. access-transfer-events; and 

B) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according 
to IETF RFC 6086 [54] and: 

a) indicating the session transfer notification response; 

b) indicating that the ATCF does not require the MSC server to redirect the speech media component of the 
session transferred by the CS to PS SRVCC access transfer; and 
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c) containing the ATGW transfer details. 

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 2: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 3: At this point, the ATCF interacts with the ATGW to release any resources reserved on PS serving leg. 
The details of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 4: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Unless the determined session being transferred is released, upon receiving the SIP INFO request carrying session 
transfer preparation, the ATCF shall: 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]. 

NOTE 5: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE 
towards the SC UE according to the SC UE information for CS to PS SRVCC (see subclause 6A.3.1). 
The details of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 6: At this point, the ATCF interacts with the ATGW to start forwarding the audio media received at the IP 

address and port provided in the ATGW transfer details according to the ATGW information for CS to PS 
SRVCC (see subclause 6A.3.1) towards the remote UE. The details of interaction between the ATCF and 
the ATGW are out of scope of this document. 

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 7: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 8: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE 
towards the MSC server according to the SDP negotiated by the MSC server in the CS serving leg. The 
ATCF also interacts with the ATGW to release any resources reserved on the PS serving leg. The details 
of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 9: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Upon receiving SIP INVITE request due to STI-rSR and if: 

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3. 1) of the registration path of the SIP 
INVITE request due to STI-rSR is set; and 

2) the home leg of the session being transfered by CS to PS SRVCC (see subclause 6A.3.1) of the registration path 
of the SIP INVITE request due to STI-rSR is set and the dialog of the home leg of the session being transfered 
by CS to PS SRVCC has not been released yet; 

the ATCF shall: 

1) send a SIP 200 (OK) response to the received SIP INVITE request due to STI-rSR according to 
3GPP TS 24.229 [2]. The ATCF shall populate the SIP 200 (OK) response with: 
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A) the Contact header field of the remote UE of the home leg of the session being transfered by CS to PS 
SRVCC; 

B) the Feature-Caps header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

C) the Accept header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

D) the Recv-Info header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

E) all header fields received in the home leg of the session being transfered by CS to PS SRVCC, which contain 
option tag(s); 

F) the P-Asserted-Identity header field received in the home leg of the session being transfered by CS to PS 
SRVCC; 

G) the Privacy header fields received in the home leg of the session being transfered by CS to PS SRVCC; 
H) the Record-Route header field that contains only the SIP URI pointing to the ATCF; 

I) the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW; 

J) the P-Charging- Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the 
"related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging- 
Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access 
leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the host name or IP 
address included in the "icid-generated-at" header field parameter of the source access leg; and 

K) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the serving leg of the session being transfered by CS 
to PS SRVCC; 

2) initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due 
to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with: 

A) the SDP offer containing the currently used media with the ATGW ports and IP addresses towards the remote 
UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types 
offered in the received SIP INVITE request due to STI-rSR; 

B) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3. 1) previously received 
from the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR; and 

C) the Target-Dialog header field containing the dialog identifier of the home leg of the session being transfered 
by CS to PS SRVCC (see subclause 6 A. 3.1) of the registration path of the SIP INVITE request due to STI- 
rSR; 

D) the Require header field containing the option tag "tdialog"; 

E) the Contact header field that contains the contact information received in the SIP INVITE request due to STI- 
rSR; 

F) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; and 

NOTE 10: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

G) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3.1) previously received from 
the SCC AS and associated with the registration path of the SIP INVITE request; and 

NOTE 1 l:Route header field(s) included in the SIP INVITE request due to STI-rSR are not inserted in the SIP 
INVITE request due to ATU-STI for CS to PS SRVCC. 

3) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 
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Upon receiving SIP INVITE request due to STI-rSR and if: 

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3. 1) of the registration path of the SIP 
INVITE request due to STI-rSR is set; and 

2) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) of the registration path 
of the SIP INVITE request due to STI-rSR is set and the dialog of the home leg of the session being transfered 
by CS to PS SRVCC has already been released; 

the ATCF shall initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE 
request due to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with: 

1) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

A) all MIME bodies of the SIP INVITE request due to STI-rSR apart from the application/sdp MIME body; and 

B) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 

NOTE 12: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

2) if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9], 
all MIME bodies of the originating SIP INVITE request from MSC server; 

3) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3.1) previously received from 
the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR; 

4) the Contact header field that contains the contact information received in the SIP INVITE request due to STI- 
rSR; 

5) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; and 

NOTE 13: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

6) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3. 1) previously received from the 
SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR. 

Upon receiving SIP Ixx or 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the ATCF 
shall: 

1) save the Contact header field included in the SIP response; and 

2) send a SIP response to the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The ATCF 
shall populate the SIP response with: 

A) the same response code as the received SIP response to the SIP INVITE request due to ATU-STI for CS to 
PS SRVCC; 

B) Record-Route header field containing the SIP URI of the ATCF; and 

C) the P-Charging- Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the 
"related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging- 
Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access 
leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the host name or IP 
address included in the "icid-generated-at" header field parameter of the source access leg. 

1 2.7.3.3 Transfer of session with active speech media component not anchored in 
ATGW 

In order to transfer the determined session being transferred with the speech media component not anchored in ATGW, 
the ATCF shall: 
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NOTE 1 : At this point, ATCF interacts with ATGW to reserve resources and provide the information needed in the 
procedures below. The details of interaction between ATCF and ATGW are out of scope of this 
document. 

1) for each registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the session of 
the SIP INFO request carrying the session transfer notification request, set: 

A) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1); and 

B) the home leg of the session being transfered by CS to PS SRVCC (see subclause 6A.3.1) to the dialog 
identifier of the home leg of the determined session being transferred; and 

2) send a SIP INFO request within the dialog of the SIP INFO request carrying the session transfer notification 
request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INFO request with: 

A) Info-Package header field with value g.3gpp. access-transfer-events; and 

B) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according 
to IETF RFC 6086 [54] and: 

a) indicating the session transfer notification response; 

b) indicating that the ATGW requires MSC server to redirect the speech media component of the session 
transferred by the CS to PS SRVCC access transfer; and 

c) containing the ATGW transfer details. 

Upon receiving a SIP INVITE request due to meida transfer from MSC server to ATGW, the ATCF shall: 

1) send a SIP 200 (OK) response to the SIP INVITE request according to 3GPP TS 24.229 [2]. 

Editor's note [WID rSRVCC-CT CR#0674]: How the ATCF associate the SIP request due to meida transfer from 
MSC server to ATGW with the session to be transferred is FES. 

NOTE 2: At this point, ATCF interacts with ATGW to establish the media bearer between MGW and ATGW. The 
details of interaction between ATCF and ATGW are out of scope of this document. 

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 3: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 4: At this point, the ATCF interacts with the ATGW to release any resources reserved on PS serving leg. 
The details of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 5: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Unless the determined session being transferred is released, upon receiving the SIP INFO request carrying session 
transfer preparation, the ATCF shall: 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]. 

NOTE 6: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE 
towards the SC UE according to the SC UE information for CS to PS SRVCC (see subclause 6A.3.1). 
The details of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 7: At this point, the ATCF interacts with the ATGW to start forwarding the audio media received at the IP 

address and port provided in the ATGW transfer details according to the ATGW information for CS to PS 
SRVCC (see subclause 6A.3.1) towards the remote UE. The details of interaction between the ATCF and 
the ATGW are out of scope of this document. 



ETSI 



3GPP TS 24.237 version 1 1 .6.0 Release 11 1 37 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 8: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 9: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE 
towards the MSC server according to the SDP negotiated by the MSC server in the CS serving leg. The 
ATCF also interacts with the ATGW to release any resources reserved on the PS serving leg. The details 
of interaction between the ATCF and the ATGW are out of scope of this document. 

NOTE 10: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Upon receiving a SIP INVITE request due to STI-rSR and if: 

1) the CS to PS SRVCC access transfer in progress flag (see subclause subclause 6A.3.1) of the registration path of 
the SIP INVITE request due to STI-rSR is set; and 

2) the home leg of the session being transfered by CS to PS SRVCC (see subclause 6 A. 3. 1) of the registration path 
of the SIP INVITE request due to STI-rSR is set and the dialog of the home leg of the session being transfered 
by CS to PS SRVCC has not been released yet; 

the ATCF shall: 

NOTE 1 1: At this point, the ATCF interacts with the ATGW to provide information needed in the procedures below 
and to request the ATGW to forward the audio media of the session being transferred from the remote UE 
to the SC UE. The details of interaction between the ATCF and the ATGW are out of scope of this 
document. 

1) send a SIP 200 (OK) response to the received SIP INVITE request due to STI-rSR according to 
3GPP TS 24.229 [2]. The ATCF shall populate the SIP 200 (OK) response with: 

A) the Contact header field of the remote UE of the home leg of the session being transfered by CS to PS 
SRVCC; 

B) the Feature-Caps header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

C) the Accept header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

D) the Recv-Info header fields received in the home leg of the session being transfered by CS to PS SRVCC; 

E) all header fields received in the home leg of the session being transfered by CS to PS SRVCC, which contain 
option tag(s); 

F) the P-Asserted-Identity header field received in the home leg of the session being transfered by CS to PS 
SRVCC; 

G) the Privacy header fields received in the home leg of the session being transfered by CS to PS SRVCC; 
H) the Record-Route header field that contains only the SIP URI pointing to the ATCF; 

I) the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW; 

J) the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the 
"related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging- 
Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access 
leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the host name or IP 
address included in the "icid-generated-at" header field parameter of the source access leg; and 
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K) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti 
media feature tag in the Contact header field received in the serving leg of the session being transfered by CS 
to PS SRVCC; 

NOTE 12: At this point the ATCF requests the ATGW to forward the audio media from the SC UE to the remote 
UE. The details of interaction between the ATCF and the ATGW are out of scope of this document. 

2) initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due 
to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with: 

A) the SDP offer containing the media with the ATGW ports and IP addresses towards the remote UE as 
provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types offered 
in the received SIP INVITE request due to STI-rSR; 

B) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3. 1) previously received 
from the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR; 

C) the Target-Dialog header field containing the dialog identifier of the home leg of the session being transfered 
by CS to PS SRVCC (see subclause 6 A. 3.1) of the registration path of the SIP INVITE request due to STI- 
rSR; 

D) the Require header field containing the option tag "tdialog"; 

E) the Contact header field that contains the contact information received in the SIP INVITE request due to STI- 
rSR; 

F) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; and 

NOTE 13: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

G) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3.1) previously received from 
the SCC AS and associated with the registration path of the SIP INVITE request; and 

3) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 14: Upon receiving a SIP 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the 
ATCF requests the ATGW to update forwarding of the audio media from the SC UE to the remote UE. 
The details of interaction between the ATCF and the ATGW are out of scope of this document. 

Upon receiving a SIP 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the ATCF shall: 

1) send a SIP BYE request to terminate the dialog between MSC Server and ATCF, following the procedures 
specified in 3GPP TS 24.229 [2]. 

Upon receiving SIP INVITE request due to STI-rSR and if: 

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3. 1) of the registration path of the SIP 
INVITE request due to STI-rSR is set; and 

2) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) of the registration path 
of the SIP INVITE request due to STI-rSR is set and the dialog of the home leg of the session being transfered 
by CS to PS SRVCC has already been released; 

the ATCF shall initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE 
request due to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with: 

1) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

A) all MIME bodies of the SIP INVITE request due to STI-rSR apart from the application/sdp MIME body; and 

B) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 
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NOTE 15:ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

2) if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9], 
all MIME bodies of the originating SIP INVITE request from MSC server; 

3) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3. 1) previously received from 
the sec AS and associated with the registration path of the SIP INVITE request due to STI-rSR; 

4) the Contact header field that contains the contact information received in the SIP INVITE request due to STI- 
rSR; 

5) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; and 

NOTE 16:The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 

6) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3.1) previously received from the 
SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR. 

Upon receiving SIP Ixx or 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the ATCF 
shall: 

1) save the Contact header field included in the SIP response; and 

2) send a SIP response to the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The ATCF 
shall populate the SIP response with: 

A) the same response code as the received SIP response to the SIP INVITE request due to ATU-STI for CS to 
PS SRVCC; 

B) Record-Route header field containing the SIP URI of the ATCF; and 

C) the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the 
"related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging- 
Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access 
leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the host name or IP 
address included in the "icid-generated-at" header field parameter of the source access leg. 

12.7.3.4 Transfer when only held or alerting session exist 

If the ATCF supports the CS to PS SRVCC, in order to transfer the held or alerting session, the ATCF shall: 

1) for each registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the session of 
the SIP INFO request carrying the session transfer notification request: 

A) set the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1); and 

B) reset the home leg of the session being transfered by CS to PS SRVCC (see subclause 6A.3.1); and 

2) send a SIP INFO request within the dialog of the SIP INFO request carrying the session transfer notification 
request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INFO request with: 

A) Info-Package header field with value g.3gpp. access-transfer-events; and 

B) application/vnd.g.3gpp.access-transfer-eventsH-xml MIME body associated with the info package according 
to IETF RFC 6086 [54] and: 

a) indicating the session transfer notification response; 

b) indicating that the ATCF does not require the MSC server to redirect the speech media component of the 
session transferred by the CS to PS SRVCC access transfer; and 

c) containing the ATGW transfer details indicating that the ATGW Transfer details content field is not 
included. 
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If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 1: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 2: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Unless the determined session being transferred is released, upon receiving the SIP INFO request carrying session 
transfer preparation, the ATCF shall send SIP 200 (OK) response to the SIP INFO request according to 

3GPPTS 24.229 [2]. 

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall: 

NOTE 3: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC 
is cancelled. 

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and 

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path 
of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see 
subclause 6A.3.1). 

NOTE 4: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of 
this subclause are not invoked. 

Upon receiving SIP INVITE request due to STI-rSR and if: 

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3. 1) of the registration path of the SIP 
INVITE request due to STI-rSR is set; and 

2) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) of the registration path 
of the SIP INVITE request due to STI-rSR is not set; 

the ATCF shall initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE 
request due to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with: 

1) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]: 

A) all MIME bodies of the SIP INVITE request due to STI-rSR apart from the application/sdp MIME body; and 

B) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; 

NOTE 5: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

2) if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9], 
all MIME bodies of the originating SIP INVITE request from MSC server; 

3) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3. 1) previously received from 
the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR; 

4) the Contact header field that contains the contact information received in the SIP INVITE request due to STI- 
rSR; 

5) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive 
subsequent in-dialog requests from the SCC AS; and 

NOTE 6: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route 
header field that the SCC AS will use when sending the in-dialog request toward the ATCF. 
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6) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3. 1) previously received from the 
sec AS and associated with the registration path of the SIP INVITE request due to STI-rSR. 

Upon receiving SIP Ixx or 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the ATCF 
shall: 

1) save the Contact header field included in the SIP response; and 

2) send a SIP response to the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The ATCF 
shall populate the SIP response with: 

A) the same response code as the received SIP response to the SIP INVITE request due to ATU-STI for CS to 
PS SRVCC; 

B) Record-Route header field containing the SIP URI of the ATCF; and 

C) the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the 
"related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging- 
Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access 
leg, ATCF shall include the "related-icid-generated-at" header field parameter containing the host name or IP 
address included in the "icid-generated-at" header field parameter of the source access leg. 



1 3 Roles for media adding/deleting for access transfer 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

1 3.2.1 Adding or removing media tinrougin Gm 

If the SC UE wants to add or remove media components to a session that was previously established using Gm 
reference point, the SC UE shall follow the procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If the SC UE wants to transfer media components from the source access leg to an existing target access leg (i.e the 
access legs were previously established due to the partial session transfer) using Gm reference point, the SC UE shall: 

1. add the media components to the target access leg; and 

2. remove those media components from the source access leg, 

by using procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If SC using ICS is enabled then if the SC UE wants to add or remove CS media components to a session, it shall follow 
the procedures defined in 3GPP TS 24.292 [4]. 

If the SC UE receives a SIP re-INVITE request or a SIP UPDATE request from the remote UE to add or remove media 
components to a session that was previously established using Gm, the SC UE shall: 

follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media; and 

if SC using ICS is enabled, follow the procedures defined in 3GPP TS 24.292 [4] for adding or removing CS 
media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when SC using ICS is enabled and when there is a 
single full-duplex session with speech media component over CS. If there is more than one full-duplex session with 
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speech media component, the SC UE shall release all the ongoing sessions that are not currently active before 
attempting the procedures described in this section. 

If SC using ICS is enabled and the SC UE wants to add Gm control to an existing CS session that was established 
without Gm, after registering with the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the 
PS access in accordance with 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

set the Request-URI to the static STI; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing a speech 
media component over a circuit switched bearer. The SC UE can optionally include additional PS media to the 
SDP in accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 

If SC using ICS is enabled and the SC UE receives a new SIP INVITE request containing a speech media component 
over a circuit-switched bearer in the SDP and the SCC AS PSI DN matches the B-party number of the ongoing CS call 
that was established without Gm, the SC UE shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 SCC AS 

1 3.3.1 Adding or removing media tinrougin Gm 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE, in which already existing 
media components of the session are transferred from a source access leg to an already existing target access leg (i.e. 
the target access leg was already established due to partial session transfer), the SCC AS shall update the remote UE 
using the session transfer procedures defined in subclause 10.3.2. 

NOTE: The SC UE indicates that media is switched from the source access leg to the target access leg by using the 
procedures defined in 3GPP TS 24.229 [2] for adding / removing PS media, i.e. the related connection and port 
information of the transferred media component within the SDP is changed from the source access leg to the target 
access leg. 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE or remote UE to 
add/remove new media components, to an existing access leg of the session established using Gm, the SCC AS shall 
follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures 
defined in 3GPP TS 24.292 [4] for adding or removing CS media to the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI or receives a SIP re- 
INVITE containing one or more already existing media lines in the SDP for audio indicating a CS bearer as defined in 
draft-ietf-mmusic-sdp-cs [73] the SCC AS shall: 

determine if this SIP INVITE request or SIP re-INVITE request is for an ongoing call by determining if the 
received contents of the Contact header field of the SIP request is bound to an ongoing CS call session identifier: 
and 

if the SC UE has an ongoing CS call: 

respond to the SIP INVITE request or SIP re-INVITE request in accordance with the procedures defined in 
3GPPTS 24.292 [4]; 

treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 
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if the SIP INVITE request or SIP re-INVITE request contains additional PS media, the SCC AS shall 
send a SIP re-INVITE request towards the remote UE, including the newly added PS media, in 
accordance with the procedures defined in 3GPP TS 24.229 [2]. NOTE: When using the ICS controlled 
CS bearer, only one audio call can be active at a time. Nevertheless, several calls can be held in parallel. 
If the user decides to switch to another (previously held) call, the ICS controlled CS bearer is re-used for 
this call. Therefore no specific procedures for handling of held calls in the case of ICS controlled CS 
bearer are needed. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-session with speech media 
component over CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, 
the SCC AS shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The 
SCC AS shall populate the SIP INVITE request as follows: 

set the Request-URI to the public user identity of the UE; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing speech media 
component over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlUng the CS 
call. 



14 Void 

15 Void 

16 Void 

17 Void 

18 Void 

19 Void 

20 Service continuity and IVIIVITEL interactions 

20.1 Roles for access tranfer and supplementary services 
interaction 

20.1.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for interaction of access transfer when execution of 
supplementary service as described in 3GPP TS 22.173 [24]. 

20.1.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIP besides the 
procedures described in 3GPP TS 24.607 [25]. 
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20.1.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIR besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.6 Communication Diversion (CDIV) 

Upon receiving an incoming session split across multiple access legs, if the SC UE desires to invoke the CDIV, it may 
choose any of the PS access legs to invoke the call deflection supplementary service following the procedures described 
in 3GPP TS 24.604 [27] or the CS access leg to invoke the call deflection supplementary service following the 
procedures described in 3GPP TS 24.072 [42]. 

NOTE: Communication Forwarding unconditional. Communication forwarding on no reply. Communication 
Forwarding on Busy, Communication Forwarding Not Logged-in and Communication Diversion 
Notification supplementary services are invoked by the CDIV AS as described in 3GPP TS 24.604 [27] 
independent on access type. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CDIV request from the SC UE 
on any access leg, the SCC AS shall terminate any other access legs and invoke the CDIV for that access leg according 
to the procedures described in 3GPP TS 24.604 [27]. 

20.1 .7 Communication Hold (HOLD) 

When the SC UE which is dividing an IMS session through multiple access legs, desires to invoke HOLD on one or 
more media componets, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for PS access 
legs, 3GPP TS 24.083 [43] for a CS access leg not controlled by the II interface or 3GPP TS 24.294 [44] for a CS 
access leg controlled by the II interface which contains the affected media components. 

When the SCC AS which dividing an IMS session into multiple access legs, receives a HOLD request from the SC UE 
or remote end on any access leg, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for that 
access leg. 



20.1.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CB besides the 
procedures described in 3GPP TS 24.61 1 [29]. 

20.1 .9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and MWI besides the 
procedures described in 3GPP TS 24.606 [30]. 



20.1.10 Conference (CONF) 



When the SC UE has multiple access legs and if it wants to send any CONF related requests such as SIP SUBSCRIBE 
request or SIP REFER request, the SC UE may send the request on the PS access leg as describes in 
3GPP TS 24.605 [31] or use the procedures described in 3GPP TS 24.294 [44] for a CS access leg controlled by the II 
interface. For a CS access leg without II interface control the procedures in 3GPP TS 24.084 [47] shall be used to create 
and add participants to a conference. 
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When the SC UE has multiple access legs and if it receives a request on one of the access legs for CONF service to 
replace an existing session, the SC UE shall: 

if each access les is PS access leg, follow procedures specified in 3GPP TS 24.605 [31] to establish a new 
session to the conference focus; 

if the CS access leg is not controlled by the II interface follow the procedures in 3GPP TS 24.008 [8] for 
releasing and establishing a new call towards the conference focus; and 

if the CS access leg is controlled by the II interface follow the procedures in 3GPP TS 24.294 [44] for establish 
a new session towards the conference focus. 

When the SC UE has multiple access legs and if it receives a request on one the access legs for CONF service to replace 
an existing session outside the dialog, the SC UE shall follow procedures specified in 3GPP TS 24.605 [31] to establish 
a new session to the conference focus. 

When the SC UE has multiple access legs and if the remote UE sends a request for the CONF servive to replace an 
existing session within the same dialog, the SCC AS shall deliver the request for CONF service on the Gm controlled 
any of access legs or over the II interface if II interface control is used or to the CS leg if only a CS leg exists, to the SC 
UE. 

20.1 .1 1 Explicit Communication Transfer (ECT) 

When the SC UE has multiple access legs and if it acts as the transferor UE, the SC UE may send the request for ECT 
service on any of the PS legs as specified in 3GPP TS 24.629 [32], or on the CS access leg not controlled by the II 
interface follow the procedures in 3GPP TS 24.091 [46] and on a CS access leg controlled by the II interface follow the 
procedures in 3GPP TS 24.294 [44]. 

When the SC UE has multiple access legs and if it acts as the transferee UE, the SCC AS may deliver the request for 
ECT service on any of the access legs. 

NOTE: Delivering of the request towards the CS access leg may be controlled by operator policy. 

When the SC UE has multiple access legs and if it receives an ECT request on one of the access legs, the SC UE shall 
follow the procedures specified in 3GPP TS 24.629 [32] to establish a new session to the Transfer Target. 



20.1.12 Advice of CInarge (AOC) 



When the AOC service as specified in 3GPP TS 24.647 [33] is active and if the SC UE has multiple access legs, the 
SCC AS may deliver charging information during the communication to the SC UE over any of the access legs which 
accept application/vnd.etsi.aoc+xml MIME type. 



20.1.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CUG besides the 
procedures described in 3GPP TS 24.654 [34]. 

20.1.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with 
session transfer is the same as that specified in subclause 20.1.10 for CONF service. 



20.1.15 Flexible Alerting (FA) 



There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and FA besides the 
procedures described in 3GPP TS 24.239 [35]. 
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20.1 .1 6 Communication Waiting (CW) 

Upon receiving an incoming session split across multiple access legs if the SC UE desires to invoke the CW, it may 
choose any of the access legs to invoke the CW service following to the procedures defined in 3GPP TS 24.615 [36]. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CW request from the SC UE 
on any access leg, the SCC AS shall invoke the CW service following the procedures defined in 3GPP TS 24.615 [36]. 

20.1 .1 7 Completion of Communications to Busy Subscriber 
(CCBSyCompletion of Communications by No Reply (CCNR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CCBS/CCNR 
besides the procedures described in 3GPP TS 24.642 [37]. 

20.1.18 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 

3GPPTS 24.182 [38]. 

When the terminating network is providing CAT, PS to CS access transfer for calls in alerting phase is only supported if 
a 180 (Ringing) response is sent. This is not required as part of the CAT service. 

20.1.19 Malicious Communication IDentification (MCID) 

When invoking the MCID service in temporary subscription mode and there are multiple active access legs for the 
session, the SC UE may send the SIP re-INVITE request for invoking MCID service as defined in 3GPP TS 24.616 [39] 
on any of the access legs. 

20.1.20 Reverse Charging 

The interaction of the Reverse Charging service according to 3GPP TS 24.647 [33] with access transfer is not specified 
in this version of the specification. 

20.1 .21 Personal Network Management (PNM) 

The interaction of the PNM service according to 3GPP TS 24.259 [40] with access transfer is not specified in this 
version of the specification. 

20.1.22 Customized Ringing Signal (CRS) 

The interaction of the CRS service according to 3GPP TS 24.183 [41] with access transfer is not specified in this 
version of the specification. 

20.2 Void 
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21 Void 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 
SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4. 1 and 4.2 applies with the additions 
specified below: 

tel:+l-237-555-l 111 represents the public user identity of SC UE A. 

tel:+l-237-555-2222 represents the public user identity of UE B. 

sip:sccasl. homel.net represents the Internet host of SCC AS. 

sip:pstops. transfer@sccasl.homel.net represents the PS to PS STL 

sip:domain.xfer@ sccas.homel.net representing the static STL 

#### represents the contents in the headers are not shown and does not impact the implementation of the flows. 

sip:homel .net represents the home network domain name of the SC UE A. 

sip:additional. session.xfer@sccas.homel.net represents the additional transferred session SCC AS URL 

sip:additional.session. xfer.pscssrvcc@sccas.homel.net represents the additional transferred session SCC AS 
URI for PS to CS SRVCC. 

- tel:+l-237-888-9999 represents the STN-SR owned by ATCF. 
sip:reg@atcf.visited2.net;lr represents the ATCF URI for originating requests. 
sip:termsdgfdfwe@ atcf.visited2.net represents the ATCF URI for terminating requests. 
sip:atcf. visited2.net represents the ATCF management URI. 

sip:sti-sr@atcf. visited2.net represents the STI-rSR owned by ATCF. 

- sip:AUT-STIl @sccas.homel.net represents the ATU-STI for PS to CS SRVCC. 

- sip:cs2ps@sccasl.homel.net represents the ATU-STI for CS to PS SRVCC. 
sip:termpdfjkghlj @mscl23.visited2.net;lr represents the MSC URI for terminating requests. 
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sip:mscl23. visited2.net represents the MSC management URI. 

Each signalHng flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A. 2-1 is used. 

INVITE 
► SIP message 



SETUP 



CS message 
Media over a PS connection 

Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the ISC procedures, the SC UE is registered in IM CN subsystem 
and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IM CN subsystem 
are defined in 3GPP TS 24.228 [3]. 

A.3. 2 Signalling flows for multiple registration for service 
continuity 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the UE also supports the Controller UE procedures for lUT 
transfer. In this example the SCC AS receives the registration state information that it needs to implement SCC specific 
requirements from the third-party SIP REGISTER request. 
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S-CSCF 
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Register#2 
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SCCAS 
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-22. SIP Register*- 
"•-23. 200 OK — 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#1. 
NOTE 1: Eor clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 

Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sipiregistrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl jubliclohomel .net>; tag=4f a3 

To: <sip :userl_publicl@homel .net> 

Contact: <sip: [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance = "< 
urn:gsma: imei : 90420156-025763-0 >";+g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; +g. 3gpp. access type=" eel lularl" ;expires=6000 
00 

Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 
uri=" sip: registrar .homel .net" , response="662 9f ae493 93a053 97450978507c4ef 1" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=2468 ; 
port-s=1357 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi -s =8765432 1 ; port- 
c=B642; port-s=7531 

Require: sec-agree 

Proxy-Require: sec-agree 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 
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2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the SIP REGISTER request towards I-CSCF. The P- 
CSCF adds a Path header field with a flow token and includes the 'ob' parameter 

Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF) 



REGISTER sip: registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Info : 

Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl .net ; lr ,-ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
From: 
To: 

Contact : 
Call-ID: 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri=" sip: registrar .homel .net" , response="662 9f ae493 93a053 97450978507c4ef 1" , integrity- 

protected= "yes " 
CSeq: 

Supported: 
Content-Length : 



3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URI in the first Path header field has an "ob" URI parameter, it include a Require header field with the option- 
tag "outbound". 

Table A.3.2-4: SIP 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscfl .visitedl .net ;branch=z 9hG4bK24 Of 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Path: <sip : termOpcscf 1 .visitedl .net; lr;ob> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

From: 

To: 

Call-ID: 

Contact: <sip: [5555 :: aaa :bbb : ccc : ddd] : 1357;comp=sigcomp>; 
pub-gruu=" sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf G" 
; temp-gruu="sip: tgruu. 7hs==jd7vnzga5w7fajsc7-ajd6fabz0f 8g5@example . com;gr" 
; +sip. instance="< urn:gsma : imei : 90420156-025763-0 >"+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" :+g . 3gpp . access type="cellularr' 
;expires=600000 

CSeq: 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2@homel . net> , <sip :userl_public3@homel .net>, <sip:+l-212- 
555-llll(Shomel .net ;user=phone> 

Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 
7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 
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After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party SIP REGISTER 
request to the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 

REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG499ffhy 

Max-Forwards: 70 

From: <sip : scscf 1 . homel . net> ; tag=538ya 

To : <sip : userl_publicl®homel . net> 

Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Contact: <sip : scscf 1 .homel .net>; expires=600000 

CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: message/sip 

REGISTER sip:registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib®pcscf 1 .visitedl .net ; lr ,-ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
From: <sip :userl_publicl®homel .net>; tag=4f a3 
To: <sip :userl_publicl@homel .net> 

Contact: <sip: [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance="< 
urn:gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ;+g. 3gpp . ics= "principal" ;+g. 3gpp.accesstype="cellularl";expires = 600000 
Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 
nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 
uri=" sip: registrar .homel .net" , response="662 9f ae4 9393a0 53974 50 97850 7c4ef 1" 
CSeq: 2 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 

--boundaryl 

Content-Type: message/sip 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Path: <sip : termOpcscf 1 .visitedl .net; lr;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From: <sip :userl_publicl®homel .net>; tag=4f a3 
To : <sip : userl_publicl®homel . net> ; tag=3ecl 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 
pub-gruu="sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6" 
; temp -gruu=" sip : tgruu. 7hs==jd7vnzga5w7f aj sc7-ajd6f abzOf 8g5@example . com;gr" 
;+sip . instance="< urn:gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref ="urn%3Aurn- 7%3gpp- 

service . ims . icsi .mmtel" ; +g. 3gpp . ics = "principal "+g. 3gpp.accesstype="cellularl" 

;expires=600000 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2®homel .net>, <sip :userl_public3®homel .net>, <sip: +1-212-555- 

llll®homel .net ;user=phone> 

CSeq: 2 REGISTER 

Content-Length: 

- - boundaryl - - 

8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 
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9. UE connects to a new IP-CAN 

The UE connects to a new IP -CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCFh-2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sipiregistrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 

Max- Forwards : 70 

P-Access-Network-Info: IEEE-802 . lib 

From: <sip :userl_publicl@homel .net>; tag=2hiue 

To : <sip : userl_publicl@homel . net> 

Contact: <sip : [5555 :: aaa :bbb : ccc : eee] ;comp=sigcomp>; reg-id=2; +sip . instance="< 
urn:gsma: imei : 90420156-025763 -0>;+g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics = "principal" ; +g. 3gpp.accesstype="wlan2";expires=600000 

Call-ID: E05133BD26DD 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 
nonce="", uri="sip: registrar .homel .net " , response="" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 
port-s=5678 

Require: sec-agree 

Proxy-Require: sec-agree 

CSeq: 1 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header field with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 

16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 

19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 

22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 

Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS) 

REGISTER sip: sccas.homel.net /2 . 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG499ffhy 

Max-Forwards: 70 

From: <sip : scscfl . homel . net> ; tag=538ya 

To: <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Call-ID: lasdaddlrf jflslj40a222 

Contact: <sip : scscfl .homel .net>; expires=600000 

CSeq: 87 REGISTER 

Content-Type : multipart/mixed;boundary="boundaryl" 

Content-Length: (...) 

--boundaryl 

Content-Type: message/sip 

REGISTER sip:registrar .homel .net SIP/2.0 
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via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa :bbb : ccc : eee] : 13 57;comp=sigcomp;branch=z9hG4bICnashds7 
Max-Forwards: 69 

P-Access-Network-Info: IEEE-802 . lib 

Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl .net ; lr ,-ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 
From: <sip : userl_publicl®homel .net>; tag=2hiue 
To: <sip :userl_publicl@homel .net> 

Contact: <sip: [5555: : aaa :bbb : ccc : eee] ;comp=sigcomp>;reg-id=2 ;+sip . instance="< 
urn:gsma : imei : 90420156-025763- 0>;+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ;+g. 3gpp . ics = "principal" ; +g. 3gpp . access type ="wlan2 " ;expires = SOOOOO 
Call -ID: apb0 3aOs0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 
nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 
uri=" sip: registrar .homel .net" , response="6 62 9f ae4 93 93a0 53 974 5 978 5 7c4ef 1" 
CSeq: 3 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 

--boundaryl 

Content-Type: message/sip 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p. homel. net ;branch=z9hG4bK351g45.1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : eee] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
Path: <sip : termOpcscf 1 .visitedl .net; lr;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From: <sip :userl_publicl@homel .net>; tag=2hiue 
To : <sip : userl_publicl®homel . net> ; tag=2da87 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp = sigcomp> ; 

pub-gruu="sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6" 
; temp -gruu=" sip : tgruu. 7hs==jd7vnzga5w7f aj sc7-ajd6f abzOf 8g5@example . com;gr" 
;+sip . instance="<urn:gsma : imei : 90420156-025763- 0>";+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- 
service . ims . icsi .mmtel" ;+g. 3gpp . ics= "principal" ; +g. 3gpp . accesstype="wlan2" 
;expires=600000 
Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2®homel .net>, <sip :userl_public3®homel .net>, <sip: +1-212-555- 
llll@homel . net ;user=phone> 
CSeq: 3 REGISTER 
Content-Length: 

- - boundaryl - - 

23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 

A.3.3 Signalling flows for registration with SRVCC enhancements 

The signalling flows shown in figure A. 3. 3-1 gives an example flow for UE registration when ATCF is invoked. 
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Figure A.3.3-1 registration withi SRVCC enhiancements 

1. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.3-1 

UE sends the unprotected SIP REGISTER request to P-CSCF. 

Table A.3.3-1 : SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=2hiue 

To : <sip : userl_publicl@homel . net> 

Contact : <sip:[5555:: aaa :bbb : ccc : eee] ;comp=sigcomp>; +sip . instance="<urn:gsma : imei : 90420156- 

025763 -0>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Call-ID: E05133BD26DD 
Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 

nonce="", uri= "sip: homel .net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, gruu 
Content-Length: 



2. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.3-2 
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The P-CSCF forwards the SIP REGISTER request towards ATCF. 

Table A.3.3-2: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel.net SIP/2.0 

Path: <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 

Route : <sip : regOatcf . visited2 .net; lr> 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ;orig-ioi="12 34 5" 

Via: SIP/2. 0/UDP pcscfl .visited2 . net : 5060 ;branch=z9hG4bKnas56565 , SIP/2. 0/UDP 

[5555 : :aaa:bbb:ccc :eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5 060 ; received=5555 : :aaa:b 
bb: ccc :eee 
Max-Forwards: 69 
P-Access-Network-Inf o : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Route: ATCF URI for originating requests (as configured in P-CSCF). 

3.-4. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.3-3 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request along the Route header fields. 

Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel.net SIP/2 . 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>"; +g. 3gpp . atcf -mgmt= 

"<sip:atcf . visited2 .net>" ; +g. 3gpp.atcf - 

path="<sip: termsdgf dfweOatcf . visited2 .net>" ; +g. 3gpp. mid- call ; +g. 3gpp. srvcc- alerting 
Path: <sip : termsdgfdfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 
Route: <sip : icscf .homel .net ; lr> 
P-Visited-Network-ID : 
P-Charging-Vector : 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscfl. visited2 .net : 5060 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5 06 ; received=5555 : :aaa:b 

bb: ccc :eee 
Max- Forwards : 68 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for 
terminating requests uniquely identifies registration path (or registration flow, if multiple registration mechanism 

is used). 

Feature-Caps: The header field contains: 

g.3gpp.atcf feature-capability indicator indicating that the ATCF role is supported by this URI; 

g.3gpp.atcf-mgmt-uri feature-capability indicator indicating the management URI of the ATCF for receiving 
SIP MESSAGE requests containing SRVCC related information and the g.3gpp.atcf-path feature-capability 
indicator. The value of the g.3gpp. atcf feature-capability indicator contains the STN-SR allocated by ATCF. 
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The value of the g.3gpp.atcf-mgmt-uri feature-capability indicator contains the ATCF management URL The 
value of the g.3gpp.atcf-path feature-capability indicator is the ATCF URI for terminating requests; 

g.3gpp. mid-call indicating that all MSC servers, which can be involved in the SRVCC procedures and which 
are in the same network as the ATCF, support the MSC server assisted mid-call feature; and 

gjgpp.srvcc-alerting indicating that all MSC servers, which can be involved in the SRVCC procedures and 
which are in the same network as the ATCF, support the SRVCC for calls in alerting phase. 

Route: URI of the entry point of the home network of the UE. 

5-8. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 

9. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.3-9 

UE sends the protected SIP REGISTER request to P-CSCF. 

Table A.3.3-9: SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 

Max- Forwards : 7 

P-Access-Network-Info : 

From: 

To: 

Contact : 

Call-ID: 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , uri= "sip: homel .net " , 

response="662 9fae493 93a053 97450978507c4ef 1" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 
Require : 
Proxy-Require : 
CSeq: 2 REGISTER 
Supported: 
Content-Length : 



10. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.3-10 

The P-CSCF forwards the SIP REGISTER request towards ATCF. 

Table A.3.3-10: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel. net SIP/2.0 

Path: <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 

Route : <sip : regOatcf . visited2 .net; lr> 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ;orig-ioi="12 34 5" 

Via: SIP/2. 0/UDP pcscfl.visited2 .net :5060;branch=z9hG4bKnas565S5, SIP/2. 0/UDP 

[5555 : : aaa: bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 
bb: ccc :eee 
Max-Forwards: 69 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Route: ATCF URI for originating requests (as configured in P-CSCF). 
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11-12. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.3-11 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request. 

Table A.3.3-11 : SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>" ;+g. 3gpp . atcf -mgmt= 

"<sip:atcf . visited2 .net>" ; +g. 3gpp.atcf - 

path="<sip: termsdgf dfweOatcf . visited2 .net>" ; +g. 3gpp. mid- call ; +g. 3gpp. srvcc- alerting 
Path: <sip : termsdgfdfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 
Route: <sip : icscf .homel .net ; lr> 
P-Visited-Network-ID : 
P-Charging-Vector : 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscf 1 . visited2 .net : 5 06 ;branch=z9hG4bKnas56565, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :eee 
Max- Forwards : 68 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for 
terminating requests uniquely identifies registration path (or registration flow, if multiple registration mechanism 
is used). 

Feature-Caps: The header field contains 

g.3gpp.atcf feature-capability indicator indicating that the ATCF role is supported by this URI; 

g.3gpp.atcf-mgmt-uri feature-capability indicator indicating the management URI of the ATCF for receiving 
SIP MESSAGE requests containing SRVCC related information and the g.3gpp.atcf-path feature-capability 
indicator. The value of the g.3gpp. atcf feature-capability indicator contains the STN-SR allocated by ATCF. 
The value of the g.3gpp.atcf-mgmt-uri feature-capability indicator contains the ATCF management URI. 
The value of the g.3gpp.atcf-path feature-capability indicator is the ATCF URI for terminating requests. 

g.3gpp. mid-call indicating that all MSC servers, which can be involved in the SRVCC procedures and which 
are in the same network as the ATCF, support the MSC server assisted mid-call feature. 

g.3gpp.srvcc-alerting indicating that all MSC servers, which can be involved in the SRVCC procedures and 
which are in the same network as the ATCF, support the SRVCC for calls in alerting phase. 

Route: URI of the entry point of the home network of the UE. 

13.-14.SIP 200 (OK) response (S-CSCF to ATCF) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 

15.-16.SIP 200 (OK) response (ATCF to UE) 

The ATCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
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Table A.3.3-15: 200 OK response to the REGISTER request (ATCF towards UE) 



SIP/2.0 200 OK 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>" 

Path: <sip : termsdgfdfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Charging-Vector : 

Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscfl.visited2 .net : 5 060;branch=z9hG4bKnas5S5e5 , SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :eee 
Max-Forwards: 66 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Content-Length : 



Feature-Caps: The header field contains g.3gpp.atcf feature-capabihty indicator indicating that the ATCF role 
is supported. 

17. SIP REGISTER request (S-CSCF to SCC AS) - see example in table A.3.3-17 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 
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Table A.3.3-17: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/TCP scscf 1 . homel . net ;branch=z9hG499f f hy 

Max- Forwards : 70 

From: <sip : scscf 1 .homel .net>; tag=538ya 

To: <sip :userl_publicl®homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Call-ID: lasdaddlrf jflslj40a222 

Contact: <sip : scscf 1 .homel .net>; expires=600000 

CSeq: 87 REGISTER 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: message/sip 

REGISTER sip: homel. net SIP/2.0 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>" ;+g. 3gpp . atcf -mgmt= 

"<sip:atcf . visited2 .net>" ; +g. Sgpp.atcf - 

path="<sip: termsdgf df we@atcf . visited2 .net>" ; +g. 3gpp. mid- call ; +g. 3gpp. srvcc- alerting 
Path: <sip: termsdgf dfweOatcf . visited2 .net>, <sip : aga2gfgf®pcscf 1 . visited2 .net : 5070 ;ob> 
P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi="12 34 5" 
Via: SIP/2. 0/UDP icscf .visited2 . net : 5060 ;branch=z9hG4bKnas8866 ; SIP/2. 0/UDP 

atcf .visited2.net :5060;branch=z9hG4bKnas5889; SIP/2 .0/UDP 

pcscfl. visited2.net: 5 06 0;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :eee 
Max-Forwards: 66 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip :userl_publicl@homel .net>; tag=2hiue 
To : <sip :userl_publicl@homel .net> 
Contact: <sip: [5555: : aaa :bbb : ccc : eee] ; comp=sigcomp> ; +sip . instance = " <urn : gsma : imei : 90420156- 

0257G3-0>;+g. 3gpp. icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Call-ID: E05133BD26DD 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce="", uri="sip:homel .net " , response="" 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, gruu 
Content-Length: 

--boundaryl 

Content-Type: message/sip 

SIP/2.0 200 OK 

Path: <sip: termsdgf dfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 

Via: SIP/2. 0/UDP icscf .visited2 . net : 5060 ;branch=z9hG4bKnas8866 ; SIP/2. 0/UDP 

atcf .visited2 .net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2 .0/UDP 

pcscfl. visited2 .net : 5 06 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :eee 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From: <sip :userl_publicl@homel .net>; tag=2hiue 
To : <sip : userl_publicl@homel . net> ; tag=2da87 
Call-ID: E05133BD26DD 
Contact : 

<sip: [5555: : aaa : bbb : CCC : ddd] : 1357 ; comp=sigcomp> ; +sip . instance="<urn:gsma : imei : 90420156- 

025763 - 0> "; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
;pub-gruu= "sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6" 
; temp-gruu="sip: tgruu. 7hs==jd7vnzga5w7f aj sc7-ajd6f abzOf 8g5@example. com;gr" ;expires = 60 00 
Supported: path, gruu 
P-Associated-URI : <sip :userl_public2@homel .net>, <sip :userl_public3@homel .net>, <sip:+l-212- 

555-llll(ahomel .net ;user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

--boundaryl-- 



18. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 
19.-20.SIP MESSAGE request with SRVCC related information (SCC AS to ATCF) 
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The sec AS sends the SIP MESSAGE request with SRVCC related information towards the ATCF serving the 
registered UE. 

Table A.3.3-19: SIP MESSAGE request (SCC AS towards ATCF) 



MESSAGE sipiatcf .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP sccasl.homel.net :5060;branch=z9hG4bKnas588339 

Max- Forwards : 70 

From: <sip : sccasl .homel . net> ; tag=aassd 

To: sip : atcf . visited2 .net 

Call-ID: sdvasdfgfasdf 

CSeq: 56561 MESSAGE 

Content-Length: . . . 

P-Asserted- Identity : sip : sccasl .homel .net 

Content -Type : application/vnd. 3gpp . SRVCC- info+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<SRVCC-infos> 

<SRVCC-info ATCF- Path-URI=" sip :termsdgfdfwe@atcf .visited2 .net"> 
<ATU-STI>sip: sccasl . homel . net </ATU-STI> 
<C-MSISDN>tel:+l-23 7-555-llll</C-MSISDN> 
</SRVCC-info> 
</SRVCC-infos> 



Request-URI: ATCF management URI 
P-Asserted-Service: SCC AS URI 
body: SRVCC related information 
21.-22.SIP 200 (OK) response (ATCF to SCC AS) 

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request. 

23. Store STN-SR in HSS (SCC AS to HSS) 

SCC AS provides the received STN-SR into the HSS to replace the STN-SR pointing to the SCC AS or the 
previously stored STN-SR pointing to other ATCF. 

NOTE: step 23 can be started in parallel to step 19. 

24. Notify MME that STN-SR was changed (HSS to MME) 

HSS provides the STN-SR to the MME because of the change of the subscription data. 

A.3.4 Signalling flows for registration with SRVCC enhancements 
from UE supporting CS to PS SRVCC 

The signalling flows shown in figure A. 3. 4-1 gives an example flow for UE registration when ATCF is invoked. UE 
and ATCF are also enhanced for CS to PS SRVCC. 
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Figure A.3.4-1 registration with CS to PS SRVCC enhancements 

1. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.4-1 

UE sends the unprotected SIP REGISTER request to P-CSCF. 
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Table A.3.4-1 : SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=2hiue 

To : <sip : userl_publicl@homel . net> 

Contact : 

<sip: [5555: : aaa : bbb : CCC : ddd] : 5432 ; comp=sigcomp> ; +sip . instance="<urn:gsma : imei : 90420156- 

025763 -0>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. cs2ps- 

srvcc ; +g . 3gpp . cs2ps-srvcc-alerting 
Call-ID: E05133BD26DD 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce="", uri="sip:homel .net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, gruu 
Content-Length: 



Contact header field: media feature tag g.3gpp.cs2ps-srvcc indicates support of the CS to PS SRVCC in the UE; 
and media feature tag +g.3gpp.cs2ps-srvcc-alerting indicates support of the CS to PS SRVCC in 
alerting phase in the UE. 

2. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.4-2 

The P-CSCF forwards the SIP REGISTER request towards ATCF. 

Table A.3.4-2: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel. net SIP/2.0 

Path: <sip:aga2gfgf Opcscf 1 . visited2 .net : 5070, •ob> 

Route : <sip : regOatcf . visited2 .net; lr>, <sip:icscf .homel .net; lr> 

P-Visited-Network-ID : "Visited Network Number 1" 

P-Charging-Vector: #### 

Via: SIP/2. 0/UDP pcscfl.visited2 .net :5060;branch=z9hG4bKnas56565, SIP/2. 0/UDP 

[5555 : : aaa: bbb: ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5 060 ; received=5555 : :aaa:b 
bb: ccc :ddd 
Max- Forwards : 69 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Route: ATCF URJ for originating requests (as configured in P-CSCF) followed by URI of the entry point 

of the home network of the UE. 

3.-4. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.4-3 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request along the Route header fields. 
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Table A.3.4-3: SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>",- +g . 3gpp . atcf -mgmt-uri = 

"<sip:atcf . visited2 .net>" ; +g. Bgpp.atcf -path="<sip: termsdgf dfweOatcf . visited2 .net>" ; 

+g. 3gpp. cs2ps-srvcc="<sip: sti-srOatcf . visited2 .net>" 
Path: <sip: termsdgf dfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 
Route: <sip : icscf .homel .net ; lr> 
P-Visited-Network-ID : 
P-Charging-Vector : 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscf l.visited2 .net : 5 06 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :ddd 
Max- Forwards : 68 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF 

URI for terminating requests uniquely identifies registration (or registration flow, if multiple 
registration mechanism is used). 

Feature-Caps: The header field contains: 

g.3gpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF; 

g.3gpp.atcf-mgmt-uri feature-capability indicator with value containing the ATCF 
management URI; 

g.3gpp.atcf-path feature-capability indicator with value containing the ATCF URI for 
terminating requests; and 

g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by 
ATCF. 

Route: URI of the entry point of the home network of the UE. 

5-8. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 

9. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.4-9 

UE sends the protected SIP REGISTER request to P-CSCF. 
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Table A.3.4-9: SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 

Max-Forwards: 70 

P-Access-Network-Info : 

From: 

To: 

Contact : 

<sip: [5555: : aaa : bbb : CCC : ddd] : 5432 ; comp=sigcomp> ; +sip . instance="<urn:gsma : imei : 90420156- 

025763 -0>, -+9. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. cs2ps- 

srvcc ; +g . 3gpp . cs2ps-srvcc-alerting 
Call-ID: 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , uri="sip :homel .net ' 

response="662 9fae493 93a053 97450978507c4ef 1" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 
Require : 
Proxy-Require : 
CSeq: 2 REGISTER 
Supported: 
Content-Length: 



Contact header field: media feature tag g.3gpp.cs2ps-srvcc indicates support of the CS to PS SRVCC in the UE; 
and media feature tag +g.3gpp.cs2ps-srvcc-alerting indicates support of the CS to PS SRVCC in 
alerting phase in the UE. 

10. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.4-10 

The P-CSCF forwards the SIP REGISTER request towards ATCF. 

Table A.3.4-10: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel. net SIP/2.0 

Path: <sip:aga2gfgf Opcscf 1 . visited2 .net : 5070, •ob> 

Route : <sip : regOatcf . visited2 .net; lr>, <sip:icscf .homel .net; lr> 

P-Visited-Network-ID: "Visited Network Number 1" 

P-Charging-Vector: #### 

Via: SIP/2. 0/UDP pcscfl .visited2 . net : 5060 ;branch=z9hG4bKnas56565 , SIP/2. 0/UDP 

[5555 : : aaa: bbb: ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5 060 ; received=5555 : :aaa:b 
bb: ccc :ddd 
Max- Forwards : 69 
P-Access-Network-Inf o : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length: 



Route: ATCF URI for originating requests (as configured in P-CSCF) followed by URI of the entry point 

of the home network of the UE. 

11-12. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.4-11 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request. 
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Table A.3.4-11 : SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Feature- Caps : *;+g. 3gpp . atcf ="<tel :+l-237-888-9999>"; +g . 3gpp . atcf -mgmt-uri= 

"<sip:atcf . visited2 .net>" ; +g. Bgpp.atcf -path="<sip: termsdgf dfweOatcf . visited2 .net>" ; 

+g. 3gpp. cs2ps-srvcc="<sip: sti-sr@atcf . visited2 .net>" 
Path: <sip: termsdgf dfweOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5 070 ;ob> 
Route : <sip : sdvf asdgf 34t4®pcscf 1 . visited2 .net : 5080> 
P-Visited-Network-ID : 
P-Charging-Vector : 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscf l.visited2 .net : 5060 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :ddd] ; comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :ddd 
Max- Forwards : 68 
P-Access-Network-Info : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported: 
Content-Length : 



Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF 

URI for terminating requests uniquely identifies registration (or registration flow, if multiple 
registration mechanism is used). 

Feature-Caps: The header field contains: 

g. Bgpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF; 

g.3gpp.atcf-mgmt-uri feature-capability indicator with value containing the ATCF 
management URI; 

g.3gpp.atcf-path feature-capability indicator with value containing the ATCF URI for 
terminating requests; and 

g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by 
ATCF. 

Route: URI of the entry point of the home network of the UE. 

13.-14.SIP 200 (OK) response (S-CSCF towards ATCF) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
15.-16.SIP 200 (OK) response (ATCF towards UE)- see example in table A.3.4-15 

The ATCF sends a SIP 200 (OK) response towards the P-CSCF indicating that registration was successful. 
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Table A.3.4-15: 200 OK response to the REGISTER request (ATCF towards UE) 



SIP/2.0 200 OK 

Feature -Caps : * ; +g. 3gpp .atcf = "<tel:+l-237-888-9999>";+g. 3gpp . cs2ps-srvcc = "<sip : sti- 

srOatcf . visited2 .net>" 
Path: <sip: termsdgf df weOatcf . visited2 .net>, <sip : aga2gfgf@pcscf 1 . visited2 .net : 5070 ;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
P-Charging-Vector : 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2. 0/UDP 

pcscf l.visited2 .net : 5 060 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :eee] ; comp=sigcomp;branch=z9hG4bKnasiuenB ; rport=5060 ; received=5555 : :aaa:b 

bb: ccc :eee 
Max- Forwards : 66 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Content-Length : 



Feature-Caps: The header field contains: 

g.3gpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF; 
and 

g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by 
ATCF. 

17. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it 
received. 

18. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 

19.-20.SIP MESSAGE request with SRVCC related information (SCC AS towards ATCF) - see example in 
table A.3.4-19 

The SCC AS sends the SIP MESSAGE request with SRVCC related information towards the ATCF serving the 
registered UE. 

Table A.3.4-19: SIP MESSAGE request (SCC AS towards ATCF) 



MESSAGE sip:atcf .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP sccasl.homel.net :5060;branch=z9hG4bKnas588339 

Max-Forwards: 70 

From: <sip : sccasl . homel . net> ; tag=aassd 

To: sip : atcf .visited2 .net 

Call-ID: sdvasdfgfasdf 

CSeq: 56561 MESSAGE 

Content-Length: . . . 

P-Asserted- Identity : sip : sccasl .homel .net 

Content -Type : application/vnd. 3gpp . SRVCC- info+xml 

<?xml version="l . 0" ?> 
<SRVCC-infos> 

<SRVCC-info ATCF-Path-URI="sip: termsdgfdfweoatcf .visited2 .net"> 
<ATU-STI>sip: sccasl .homel .net</ATU-STI> 
<C-MSISDN>tel:+l-23 7-555-llll</C-MSISDN> 
<anyExt> 

<CS2 PS -ATU-STI>sip:cs2ps®sccasl. homel. net </CS2PS-ATU-STI> 
</anyExt> 
</SRVCC-info> 
</SRVCC-infos> 



Request-URI: ATCF management URI 
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P-Asserted-Identity: SCC AS URI 

body: SRVCC related information. The CS2PS-ATU-STI element contains the ATU-STI to be used in 

CS to PS SRVCC. 

21.-22.SIP 200 (OK) response (ATCF towards SCC AS) 

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request. 

23. Store STN-SR in HSS (SCC AS to HSS) 

SCC AS provides the received STN-SR into the HSS to replace the STN-SR pointing to the SCC AS or the 
previously stored STN-SR pointing to other ATCF. 

NOTE: step 23 can be started in parallel to step 19. 

24. Notify MME that STN-SR was changed (HSS to MME) 

HSS provides the STN-SR to the MME because of the change of the subscription data. 

25.-26.SIP MESSAGE request with ATGW information for CS to PS SRVCC (ATCF towards UE) - see 
example in table A.3.4-25 

Table A.3.4-25: SIP MESSAGE request (ATCF towards UE) 



MESSAGE sip: [5555 : :aaa:bbb:ccc :ddd] : 5432;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP atcf .visited2 .net :5060;branch=z9hG4bKnas66 

Max-Forwards: 70 

Route : <sip : aga2gfgf@pcscf 1 . visited2 .net : 50 70 ;ob> 

P-Asserted- Identity : sip : sti-srOatcf . visited2 .net 

From: sip : sti-srOatcf . visited2 .net ; tag=aaa52 34 

To: sip: [5555: : aaa : bbb : ccc : ddd] :5432 

Call-ID: asgag34t34543 

CSeq: 1000034 

Content-Type : 

Content-Length: (...) 

Content-Disposition: render 

P-Charging-Vector: #### 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 dfgrrgr. invalid 

t=0 

m=audio 9 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: contact address of the UE 

Route : P-CS CF path header field 

application/sdp MIME body: SDP describing the set of media streams and codecs the ATGW wishes to use 
receive the media in session transferred in any later CS to PS SRVCC access transfer. The IP 
addresses and ports can contain any value as the ATGW IP address and port are selected during 
the later CS to PS SRVCC access transfer. 

27.-28.SIP 200 (OK) response (UE towards ATCF) 

The UE generates the SIP 200 (OK) response to the SIP MESSAGE request. 

29. SIP MESSAGE request with UE information for CS to PS SRVCC (UE to P-CSCF) - see example in 
table A.3.4-29 

The UE sends the SIP MESSAGE request with UE information for CS to PS SRVCC towards the ATCF. 
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Table A.3.4-29: SIP MESSAGE request (UE to P-CSCF) 



MESSAGE sip: sti-sroatcf .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visited2 .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: < sip: user Ijubliclohomel .net>; tag=17182 8 

To: sip : sti-sr@atcf . visited2 .net 

Call -ID: Cb03a0s09a2sdfglkj 49033333 

CSeq: 56561 MESSAGE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 
Content-Disposition: render 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :aaa:bbb:ccc :ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



Request-URI: the STI-rSR allocated by ATCF received in message 16 

application/sdp MIME body: SDP describing the set of media streams and codecs the UE wishes to use, along 

with the IP addresses and ports the UE would like to use to receive the media in session transferred 
in any later CS to PS SRVCC access transfer. 

30. SIP MESSAGE request with UE information for CS to PS SRVCC (P-CSCF to ATCF) - see example in 
table A.3.4-30 

Table A.3.4-30: SIP MESSAGE request (P-CSCF to ATCF) 



MESSAGE sip: sti-sr@atcf .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visited2 .net :5060;branch=z9hG4bKnas5656544, SIP/2. 0/UDP 

[5555 : : aaa: bbb: ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 

Route : <sip :orig@atcf . visited2 .net ; lr>, <sip :orig@scscf 1 .homel .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net> 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported: 
Proxy-Require : 
Security-Verify: 
Allow: 

Content-Type : 
Content-Length: (...) 
Content-Disposition : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



£75/ 



3GPP TS 24.237 version 11.6.0 Release 11 



170 



ETSI TS 124 237 V1 1.6.0 (2013-04) 



Request-URI: the STI-rSR allocated by ATCF 

Route: ATCF URI for originating requests (as configured in P-CSCF). 

application/sdp MIME body: SDP describing the set of media streams and codecs the UE wishes to use, along 

with the IP addresses and ports the UE would like to use to receive the media in session transferred 
in any later CS to PS SRVCC access transfer. 

31.-32.SIP 200 (OK) response (ATCF towards UE) 

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request. 



A.3.5 Signalling flows for UE attaching to CS domain when IVISC 
server is enhanced for ICS and for CS to PS SRVCC and 
when UE is not registered with IIVIS in PS access network 
yet 

This signalling flow shown at figure A. 3. 5-1 describes the scenario of UE attaching to CS domain when the used MSC 
server is enhanced for ICS and for CS to PS SRVCC and when the UE is not registered with IMS in PS access network 
yet. 
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Figure A.3.5-1 MSC Server enhanced for ICS performs registration on behalf of the UE 

The details of the signalling flows are as follows: 

1. CS attach (UE to MSC) 

UE performs CS attachment procedure as specified in 3GPP TS 24.008 [8]. UE indicates support of CS to PS 
SRVCC in the CS attachment procedure. 

3. CS attach accept (MSC enhanced for ICS to UE) 

The CS attach request is accepted by the network and an accept message is sent to the MS. 

3-4. REGISTER request (MSC Server enhanced for ICS to S-CSCF) - see example in table A.3.5-3 
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Table A.3.5-3: REGISTER request (MSC Server enhanced for ICS to l-CSCF) 



REGISTER sip: ics .mncOlB .mcc234 . 3gppnetwork.org SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server" 

P-Charging-Vector: #### 

Path: <sip : termpdf jkghlj@mscl2 3 . visited2 .net; lr> 

From: <sip:23415 999999999@ics .mnc015 .mcc234 . 3gppnetwork . org> ; tag=4f a3 

To: <sip:234150 999999999@ics .mnc015 .mcc234 . 3gppnetwork.org> 

Contact : <sip:[5555:: aaa :bbb: ccc : ddd] > ; expires=600000 ;+sip . instance="<urn:gsma : imei : 90420156- 

025763 - 0> "; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics = " server" 

+g. 3gpp. cs2ps-srvcc; +g. 3gpp.path="<sip: termpdf jkghlj@mscl2 3 . visited2 .net ; lr>" 
Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 
Authorization: Digest username="234150999999999@ics .mnc015 .mcc234 . 3gppnetwork.org" , realm=" 

ics.mnc015.mcc234.3gppnetwork.org", nonce="", integrity-protected="auth-done" , uri="sip: 

ics .mnc015 .mcc2 34 . 3gppnetwork.org" , response=" " 
CSeq: 1 REGISTER 
Supported: gruu 
Require: path 
Content-Length: 



Contact: The header field contains: 

g.3gpp. icsi-ref media feature tag with value of ICSI of IMS multimedia telephony 
communication service; 

g.3gpp.ics media feature tag with value indicating that the resource is a network node which is 
ICS capable; 

- g.3gpp.cs2ps-srvcc indicating support for CS to PS SRVCC; and 

g.3gpp.path media feature tag with value containing the MSC URI for terminating requests; 

5-6. 200 (OK) response (S-CSCF to MSC server enhanced for ICS) 

The S-CSCF sends a 200 (OK) response to the MSC server enhanced for ICS. 

7. REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party REGISTER request containing in the body the incoming REGISTER request 
from the PN UE and the 200 (OK) response to the incoming REGISTER request to the SCC AS. 

8. 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS sends a 200 (OK) response to the S-CSCF indicating the third party REGISTER was successful. 

A.3.6 Signalling flows for UE attaching to CS domain when MSC 
server is enhanced for ICS and for CS to PS SRVCC and 
when UE is already registered with IMS in PS access 
network 

The signalling flow shown at figure A. 3. 6-1 describes the scenario of UE attaching to CS domain when MSC server is 
enhanced for ICS after the UE has already registered with IMS in PS access network. The scenario expects that UE, 
MSC server enhanced for ICS, ATCF and SCC AS are enhanced for CS to PS SRVCC. 
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Figure A.3.6-1 registration with SRVCC enhancements 



1. SC UE attempts to registers with IMS in PS access network. The signalling flow described in annex A.3.4 
is performed. 

2. SC UE attempts to attach to CS domain. MSC server enhanced for ICS registers with IMS without 
knowing the STN-SR of the ATCF selected during the registration of UE with IMS using PS domain. The 
signalling flow described in annex A.3.5 is performed. 

3.-4. SIP MESSAGE request with CS to PS SRVCC information (SCC AS to MSC server) - see example in 
table A.3.6-3 

The SCC AS detects that the UE has a registration path over a PS domain where ATCF is included and therefore 
the SCC AS provides information about the registration path of the UE over a PS domain to the MSC server. 

Table A.3.6-3: SIP MESSAGE request (SCC AS towards MSC server) 



MESSAGE sip:mscl23 .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP sccasl.homel.net : 5060, -branch=z9hG4bKnas588339 

Max- Forwards : 70 

From: <sip:sccasl .homel .net>; tag=aassd 

To: sip :mscl23 . visited2 .net 

Call-ID: sdvasdfgf asdf sdfwefw 

CSeq: 44561 MESSAGE 

Content-Length: . . . 

P-Asserted- Identity : sip:sccasl .homel .net 

Accept -Contact : * ;g. 3gpp .path="<sip : termpdf jkghlj@mscl23 . visited2 .net; lr>" /explicit ; require 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 
<srvcc-ext> 

<PS-reg-inf o Path="sip : termpdf jkghlj(amscl2 3 . visited2 .net ; lr"> 

<ATCF-Management-URI>sip:atcf .visited2 .net</ATCF-Management-URI> 

<C-MSISDN>tel: +1-237 -555- 1111</C-MSISDN> 

< c s2ps-srvcc-alerting>true</cs2ps-srvcc- alert ing> 

</PS-reg-info> 
</srvcc-ext> 



Request-URI: public user identity registered by the MSC server as provided in the step 2 

P-Asserted-Identity: SCC AS URI 

Accept-Contact:g.3gpp.path media feature tag containing the MSC URI for terminating requests provided in the 
SIP REGISTER request in the step 2. 
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body: CS to PS SRVCC information informing the MSC server about the ATCF used in the registration 

path of the UE over a PS domain. Path attribute contains the MSC URI for terminating requests 
provided in the SIP REGISTER request in the step 2. ATCF-Management-URI element contains 
the ATCF management URI of the ATCF, the C-MSISDN element contains the C-MSISDN of the 
UE, and the cs2ps-srvcc-alerting element shows the support of CS to PS SRVCC in alerting phase. 

5.-6. SIP 200 (OK) response (MSC server to SCC AS) 

The MSC server generates the SIP 200 (OK) response to the SIP MESSAGE request. 



A. 4 Signalling flows for call origination for service 
continuity 

A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 

A.4.2 Session origination with PS to CS SRVCC enhancements 

The signalling flow shown in figure A.4.2- 1 gives an example of originating session set up when ATCF anchors the 
media of the session. This flow assumes that ATCF was invoked during registration. 
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Figure A.4.2-1 Signalling flows for service continuity using PS to CS SRVCC 

enhancements 

1. SIP INVITE request (UE to P-CSCF) - see example in table A.4.2-1 
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Table A.4.2-1 : SIP INVITE request (UE to P-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visited2 .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl®homel .net> 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 
c=8642; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ;comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



2. SIP INVITE request (P-CSCF to ATCF) - see example in table A.4.2-2 

Since a Feature-Caps header field with the g.3gpp.atcf feature-capabihty indicator was included in 2xx response to the 
SIP REGISTER request which created the binding of the contact address using which the SIP INVITE request is sent, 
the P-CSCF routes the SIP INVITE request to the ATCF. 
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Table A.4.2-2: SIP INVITE request (P-CSCF to ATCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

Via: SIP/2. 0/UDP pcscfl .visited2 . net : 5060 ;branch=z9hG4bKnas56565 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip :orig@atcf . visited2 .net ; lr>, <sip lorigOscscf 1 .homel .net; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Pref erred-Service : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Proxy-Require : 
Contact : 
Accept -Contact 
Allow: 

Content-Type : 
Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Route: ATCF URI for originating requests (as configured in P-CSCF) followed by the remaining Route 
header fields determined by P-CSCF. 

3. ATGW resource reservation 

The ATCF decides to anchor the media of the session and reserves the resources in the ATGW. 

4-9. SIP INVITE request (ATCF towards remote UE) - see example in table A.4.2-4 

The ATCF modifies the SDP offer without changing the dialog identifier and forwards the SIP INVITE request. The 
ATCF replaces the IP address, ports, ... with values provided by ATGW. 
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Table A.4.2-4: SIP INVITE request (ATCF towards remote UE) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Record- Route : <sip ipcscf 1 . visitedl .net; lr>, < sip : atcf .visited.net ; lr> 
Via: SIP/2. 0/UDP atcf .visited2 .net :5060;branch=z9hG4bKnas55889, SIP/2. 0/UDP 
pcscf l.visited2 .net : 5 06 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route : <sip : origOscscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Pref erred-Service : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Proxy-Require : 
Contact : 
Accept -Contact 
Allow: 

Content-Type : 
Content-Length : 

v=0 

o=- 22 333 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 8899 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



SDP offer: the IP address and ports are updated to contain the values provided by ATGW . 
10-12. SIP 183 (Session Progress) response (remote UE towards SCC AS) 
The remote UE responds with SIP 183 (Session progress) response. 

13.-15.SIP 183 (Session Progress) response (SCC AS towards ATCF) - see example in table A.4.2-13 

The SCC AS forwards the SIP 183 (Session progress) response. 
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Table A.4.2-13: SIP 183 (Session Progress) response (SCC AS towards ATCF) 



SIP/2.0 183 Session Progress 

Feature-Caps: * ;+g. 3gpp . srvcc 

Record- Route : <sip :pcscf 1 . visitedl .net; lr>, <sip:atcf .visited.net; lr>, 

<sip:scscf .homel .net; lr>, <sip:icscf .homel .net ; lr>, <sip: sccas .homel .net ; lr> 

Via: SIP/2. 0/UDP sccas . homel . net : 5060 ;branch=z9hG4bKnas522 , SIP/2. 0/UDP 
scscf .homel .net : 5060 ;branch=z9hG4bKnas889, SIP/2 . 0/UDP 
icscf .homel .net : 5060 ;branch=z9hG4bKnas225, SIP/2 . 0/UDP 
atcf. visited2.net : 5060; branch=z9hG4bKnas55889, SIP/2 .0/UDP 
pcscfl. visited2.net: 5060 ;branch=z9hG4bKnas56565, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 60 

P-Asserted- Identity: <tel:+l-212-555-2222> 

Privacy: 

From: 

To: <tel:+l-212-555-2222>; tag=aaa 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : <sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8^5 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 

Content-Length : 

v=0 

0=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 

s = - 

C=IN IP6 1234 : :55 :66 :77:88 

t = 

m=audio 4456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



Supported: The SCC AS adds the "tdialog" and the "replaces" option tags in the Supported header field header, if 
not already included. In this example the "tdialog" and the "replaces" option tags were already included. 

16. ATGW resource configuration 

The ATCF configures the resources of ATGW. 

17. SIP 183 (Session Progress) response (ATCF towards UE) - see example in table A.4.2-17 
The ATCF replaces the IP address, ports, ... in SDP answer with values provided by ATGW. 
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Table A.4.2-17: SIP 183 (Session Progress) response (ATCF towards UE) 



SIP/2.0 183 Session Progress 

Feature-Caps: * ;+g. 3gpp . srvcc 

Record- Route : <sip :pcscf 1 . visitedl .net; lr>, <sip:atcf .visited.net; lr>, 

<sip:scscf .homel .net; lr>, <sip:icscf .homel .net ; lr>, <sip: sccas .homel .net ; lr> 

Via: SIP/2. 0/UDP pcscfl .visited2 . net : 5060 ;branch=z9hG4bKnas56565 , SIP/2. 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 57 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max-Forwards: 60 

P-Asserted- Identity: <tel:+l-212-555-2222> 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9^- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 

Content-Length : 

v=0 

0=- 44 555 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 11234 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



SDP answer: the IP address and ports are updated to contain the values provided by ATGW. 

A.4.3 Call origination prior to CS to PS SRVCC 

The signalhng flow shown in figure A.4.3- 1 gives an example of originating session set up. In this flow, the ATCF 
decides to anchor the media of the session in ATGW. 
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2. The SC UE A performs a CS attach and the MSC server registers the UE A in IMS, see clause 6. 
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Regular call setup continues. 



NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

Figure A.4.3-1 Signalling flows for service continuity using CS to PS SRVCC. 

1. SC UE A registers in IMS 

The SC UE A registers in IMS. 

2. The SC UE A performs a CS attach and the MSC server registers in IMS. 

3. CC SETUP message (SC UE A to MSC server). 

The SC UE sends a CC SETUP message according to 3GPP TS 24.008 [8]. 

4. SIP INVITE request (MSC server to ATCF) - see example in table A.4.3-4 

The MSC server enhanced for ICS sends the SIP INVITE request towards the ATCF. 
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Table A.4.3-4: SIP INVITE request (MSC server to ATCF) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip : atcf 2 . visited2 .net :7531;lr><sip :orig@scscf 1 .homel .net ; lr> 

P-Asserted-Identity : tel : +1-212-555-1111 

P- Charging- Vector: icid-value="12 34bc9876e" ; icid-generated-at"5555 : : aaa :bbb : ccc :ddd" ;orig- 
ioi=visited2 .net 

Privacy: none 

From: <tel:+l-23 7-555-llll>;tag=171828 

To: < tel:+l-237-555-2222 > 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server" 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Accept : application/vnd. 3gpp . access -transfer- event s+xml;et="2" 

Recv-Info : g. 3gpp . access -transfer- events 

Contact : <sip :userl_publicl®visited2 .net>; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ti="FOCA" 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

--boundaryl 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 

<srvcc-ext> 

<Setup-info> 

<C-MSISDN>tel:+l-212-555-llll</C-MSISDN> 

<direction>initiator</direction> 
</Setup-info> 
</srvcc-ext> 
- - boundaryl - - 



Route: The ATCF management URI received from SCC AS in the SIP MESSAGE request containing CS 

to PS SRVCC information during the registration of the user is added at the top of the URIs 
received in the Service-Route header field of the SIP 200 (OK) response to REGISTER. 

application/vnd.3gpp.srvcc-ext+xml: Contains the direction of call and the C-MSISDN of the UE. 

Accept: Indicate that the MSC server is able to receive the application/vnd. 3gpp.access-transfer- 

events+xml with the event type 2. 

Recv-Info: Indicate the support for g.3gpp. access-transfer-events package. 

Contact: g.3gpp.ti media feature tag with value containing the transaction identifier specified in figure 1 1.9 

and table 11. 3 of 3GPP TS 24.007 [75] encoded by hexadecimal digit. In this example, the 
transaction identifier 74 (decimal) and the transaction identifier flag as sent by the MSC server in 
CS signalling of the originating CS call are shown. 
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5. ATCF decides whether to anchor the media in the ATGW. In this flow, the ATCF decides to anchor the 
media in the ATGW and reserves the resources in the ATGW. 

6-9. SIP INVITE request (ATCF to remote UE B) - see example in table A.4.3-6 

Table A.4.3-6: SIP INVITE request (ATCF to remote UE B) 



INVITE tel:+l-237-555-2222 SIP/2 . 

Record- Route : <sip : atcf 2 . visited2 .net; lr> 

Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas55889 , SIP/2. 0/UDP 

[5555: :aaa:bbb:ccc:ddd] :13 57; ; branch=z9hG4bKnashds7 
Max- Forwards : 

Route : <sip : origOscscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Proxy-Require : 
Contact : 
Accept -Contact 
Allow: 

Content-Type : 
Content-Length : 

v=0 

o=- 22 333 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 8899 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



SDP offer: The IP address and ports are updated to contain the values provided by ATGW. 

10-11. SIP 183 (Session Progress) response (remote UE B to SCC AS) 
The remote UE B responds with SIP 183 (Session progress) response. 
12-13. SIP 183 (Session Progress) response (SCC AS to ATCF) - see example in table A.4.3-13 
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Table A.4.3-13: SIP 183 (Session Progress) response (SCC AS towards ATCF) 



SIP/2.0 183 Session Progress 

Record- Route : <sip : atcf 2 . visited2 .net;lr>,<sip:icscfl .homel .net;lr>,<sip:scscfl .homel .net ; lr>, 
<sip: sccasl .homel .net; lr>; 

Via: SIP/2. 0/UDP scscfl . homel . net : 5060 ;branch=z9hG4bKnas889 , SIP/2. 0/UDP 
atcf .visited2 .net : 5060 ;branch=z9hG4bKnas55889, SIP/2 .0/UDP 
[5555: :aaa:bbb:ccc:ddd] : 13 5 7 ;branch=z9hG4bKnashds7 

Max- Forwards : 

P-Asserted- Identity: <tel : +1-237- 555 -2222 > 

P-Charging-Vector : icid-value="1234bc9876e@5555 : : aaa :bbb : ccc :ddd" ;orig-ioi= visited2.net 

Privacy: 

From: 

To: <tel : +l-237-555-2222>; tag=aaa 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 

Content-Length : 

Feature - Caps : * ; +g. 3gpp . srvcc 

v=0 

0=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 

s = - 

C=IN IP6 1234 : :55 :66 :77:88 

t = 

m=audio 4456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



14. Configure ATGW resources. 

The ATCF configures the resources of ATGW. 

15. SIP 183 (Session Progress) response (ATCF to MSC server) - see example in table A.4.3-15 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 11 1 84 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

Table A.4.3-15: SIP 183 (Session Progress) response (ATCF to MSC server) 



SIP/2.0 183 Session Progress 

Record- Route : <sip : atcf 2 . visited2 .net; lr>, <sip:scscfl .homel .net; lr>, 
<sip:icscfl .homel .net ; lr>, <sip: sccasl .homel .net ; lr> 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] :1357; 

Max- Forwards : 

P-Asserted- Identity : 

P-Charging-Vector : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Recv-Info : g. 3gpp . access-transfer-events ;et="l, 3,4" 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9^- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 

Content-Length : 

v=0 

0=- 44 555 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 11234 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



SDP answer: the IP address and ports are updated to contain the values provided by ATGW. 

Recv-Info: Indicates the support for the info package g.3gpp. access-transfer-events and is able to receive the 

event types 1, 3 and 4. 

16. CC CALL CONFIRM message (MSC server to SC UE A) 

Regular call setup continues. 



A.5 Signalling flows for call termination for service 
continuity 

A.5.1 Session termination using CS media 

An example flow for session termination using CS calls can be found in 3GPP TS 24.292 [4]. 

A.5.2 Call termination prior to CS to PS SRVCC 

The signalling flow shown in figure A.5.2-1 gives an example of a terminating session set up. In this flow, the ATCF 
anchors the media of the session in ATGW. 
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1. SC UE A registers in IIVIS, see clause 6. 



I 



I 



I 



I 



I 



I 



I 



Remote 
UEB 



2. The SC UE A performs a CS attach and the MSC server registers the UE A in IMS, see clause 6. 



\ 
-3. INVITE- 



10. CC_ 
SETUP 



11.CC CALL 

confirmed' 



7. INVITE ((Route: ATCF 
management URI, MSC server 
URI, XML body indicating 
terminating call + C-MSISDN))- 



-6. INVITE- 



8. Reserve ATGW 
resources 



-9. INVITE- 



-12. 183 Session Progress-^ 



13. Configure ATGW 
resources 



-14. 183 Session Progress- 



-15. 183 Session Progress- 



-4. INVITE- 
-5. INVITE- 



16. 183 Session^ 
Progress 

17. 183 Session 
Progress 

18. 183 Session Progress- 



Regular call setup continues. 



NOTE: For clarity, the SIP 100 (Trying) responses are not sliown in tine signalling flow. 

Figure A.5.2-1 Signalling flows for service continuity using CS to PS SRVCC. 

1. SC UE A registers in IMS. 

2. The SC UE A performs a CS attach and the MSC server registers in IMS. 
3-4. SIP INVITE request (Remote UE B to SCC AS) 

The remote UE sends a SIP INVITE request towards the user at SC UE A. 
5-6. SIP INVITE request (SCC AS to MSC server) - see example in table A.5.2-5 

The SCC AS forwards the SIP INVITE request towards the MSC server. 
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Table A.5.2-5: SIP INVITE request (SCC AS to MSC server) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bK871yl2 . 1 

Max-Forwards: 70 

Route : <sip:scscfl .homel .net; lr>,<sip:msc2 . visited2 .net ; lr> 

Record-Route : <sip : sccasl . homel . net ; lr> 

P-Asserted-Identity: "John Doe" <sip :userl_public2@visited2 .net>, <tel : +l-237-555-2222> 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <tel:+l-23 7-555-2222>;tag=171828 

To: tel:+l-237-555-llll 

P- Charging- Vector: icid-value="12 34bc98 76e" ; icid-generated-at=5555 : : aaa :bbb :ccc:eeee" ;orig- 
ioi=visited2 .net 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept : applicatiom/sdp, application/3gpp-ims+xml 

Contact : <sip :user2_publicl@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf G>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi . mmtel "> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Feature-Caps: * ;+g. 3gpp . srvcc 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



7. INVITE request (MSC server to ATCF) - see example in table A.5.2-7 
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Table A.5.2-7: SIP INVITE request (MSC server to ATCF) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2 .0/UDP msc2 .visited2 .net ; branch=z9hG4bK8 79111 . 1, SIP/2 .0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK8 71z34 . 1 , SIP/2 . 0/UDP 
sccasl_s .homel .net ;branch=z9hG4bK8 71yl2 . 1 

Max- Forwards : 70 

Route: <sip :atcf 2 . visited2 .net; lr>,<sip:msc2 . visited2 .net ; lr> 

Record-Route : 

<sip:atcf 2 . visited2 .net ; lr>, <sip:msc2 . visited2 .net;lr>,<sip:scscfl .homel .net ; lr>, <sip: sccas 
1 .homel .net ; lr> 

P-Asserted-Identity: "John Doe" <sip :userl_public2@visited2 .net>, <tel : +l-237-555-2222> 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :user2_publicl@visited2 .net>; tag=17182 8 

To: tel:+l-237-555-llll 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept : applicatiom/sdp, application/3gpp-ims+xml 

Contact : <sip :user2_publicl®visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp- icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel">;g. 3gpp. rsrvcc 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

P -Charging- Vector : icid-value="12 34bc98 76e" ; icid-generated-at=5555 : : aaa :bbb :ccc:eeee" ;orig- 
ioi=visited2 .net 

Feature-Caps: * ;+g. 3gpp . srvcc 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

--boundaryl 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 
< srvcc -ext> 
<Setup-info> 

<C-MSISDN>tel:+l-212-555-llll</C-MSISDN> 

<direction>receiver< /direct ion> 
< /Setup -info 
</srvcc-ext> 
- -boundaryl- - 



Route: ATCF management URI received from SCC AS in the SIP MESSAGE request containing CS to 

PS SRVCC information during the registration of the user followed by MSC server URI. 

applicatioii/vnd.3gpp.srvcc-ext+xml: Contains the direction of call and the C-MSISDN of the UE. 
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8. ATCF decides whether to anchor the media in the ATGW. In this flow, the ATCF decides to anchor the 
media in the ATGW and reserves the resources in the ATGW. 

9. SIP INVITE request (ATCF to MSC server) - see example in table A.5.2-9 

The ATCF forwards the SIP INVITE request to MSC server according to the received Route header field. 

Table A.5.2-9: SIP INVITE request (ATCF to MSC server) 



INVITE tel:+l-237-555-llll SIP/2.0 

Via: SIP/2 .0/UDP atcf2 .visited2 .net ; branch=z9hG4bK8 71x99 j a, SIP/2 . 0/UDP 
msc2 .visited2 .net ;branch=z9hG4bK879111 . 1, SIP/2 . 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK871z34 . 1, SIP/2 . 0/UDP sccasl .homel .net ;branch=z9hG4bK871yl2 . 1 

Max-Forwards: 68 

Route : <sip :msc2 . visited2 .net; lr> 

Record- 
Route : <sip:atcf 2 . visited2 .net:7531;lr>,<sip:scscfl . visited2 .net ; lr>, < sccasl .homel .net ; lr> 

P-Asserted- Identity : 

P- Charging- Vector: icid-value="12 34bc98 76e" ; icid-generated-at=5555 : : aaa :bbb :ccc:eeee" ;orig- 
ioi=visited2 .net 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Privacy: 

From: 

To:tel: 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: 

Accept : applicatiom/sdp, application/3gpp-ims+xml, application/3gpp . access -transfer- 
events+xml ; et= " 1 , 3 , 4 " 

Recv-Info : g. 3gpp . access -transfer- events 

Contact : sip:<+12375551111 @msc2 . visited2 .net ; user =phone>; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- 
service . ims .icsi . mmtel "> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Feature-Caps: * ; +g. 3gpp . srvcc 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987939999 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



SDP offer: the IP address and ports are updated to contain the values provided by ATGW. 

Accept: Indicates that the ATCF is able to receive the application/3gpp.access-transfer-events+xml with 

event types 1, 3 and 4. 

Recv-Info: Indicates that the ATCF support receiving the g.3gpp. access-transfer-events info package. 

10. CC SETUP message (MSC server to UE A) 
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The MSC server sends a CC SETUP message. The mapping of the INVITE request to the CC SETUP message is 
described by 3GPP TS 29.292 [18]. 

11. CC CALL CONFIRM message (UE A to MSC server) 

The UE sends a CC CALL CONFIRM message in accordance to 3GPP TS 24.008 [8]. 

12. SIP 183 (Session Progress) response (MSC server to ATCF) - see example in table A.5.2-12 

The MSC server sends a SIP 183 (Session Progress) response. The CC CONFIRMED message is mapped to the 
SIP 183 (Session Progress) response as described in 3GPP TS 29.292 [18]. 

Table A.5.2-12: SIP 183 (Session Progress) response (MSC server to ATCF) 



SIP/2.0 183 Session Progress 

Via: 

Route : sip : atcf 2 . visited2 .net :7531;lr;>; <sip:scscfl . visited2 .net; lr>> 

Record- Route : <sip:scscfl . visited2 .net; lr>,<sip:atcf2 . visited2 .net : 7531; Ir; > 

P-Asserted-Identity : tel : <+12375551111> 

P- Called- Party- ID :tel:< +12 3 75 5 5 1111 > 

P -Charging- Vector : icid-value="12 34bc98 76e" ; icid-generated-at=5555 : : aaa :bbb :ccc:eeee" ;orig- 
ioi=visited2 .net 

From: 

To: <tel: +1-237- 555 -2222 >;tag=314159 

Call-ID: 

Cseq: 

Require: lOOrel 

Contact : <sip :userl_publicl@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ti="70D8" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Rseq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

Recv-Info : g. 3gpp . access- transfer-events;et= "2" 

v=0 

o=- 2987933615 2987939999 IN IP6 8888 :: 111 : 222 : 333 : 666 

s = - 

c=IN IP6 8888 : :111:222 :333 :666 

t = 

m=video RTP/AVP 98 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des: qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxptime : 2 



Recv-Info: Indicates that the ATCF support receiving the g.3gpp. access-transfer-events info package with 

event type 2. 

Contact: g.3gpp.ti media feature tag with value containing the transaction identifier specified in figure 1 1.9 and 
table 1 1.3 of 3GPP TS 24.007 [75] encoded by hexadecimal digit. In this example, the transaction identifier 88 
(decimal) and the transaction identifier flag as sent by the MSC server in CS signalling of the terminating CS call 
are shown. 

13. Configure ATGW resources 

The ATCF configures resources in the ATGW. 

14. SIP 183 (Session Progress) response (ATCF to MSC server) - see example in table A.5.2-14 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 11 1 90 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

Table A.5.2-14: SIP 183 (Session Progress) response (ATCF to MSC server) 



SIP/2.0 183 Session Progress 

Via: 

Route: sip : atcf 2 . visited2 .net : 7531; Ir; >; <sip : scscf 1 .homel .net ; lr>;g. 3gpp . srvcc me 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : atcf 2 . visited2 .net : 75 31; Ir; > 

P-Asserted- Identity: <tel:+l-237-555-llll> 

P- Called- Party- ID: <tel : +1-237- 555- 1111> 

P- Charging- Vector: icid-value="12 34bc98 76e" ; icid-generated-at=5555 : : aaa :bbb :ccc:eeee" ;orig- 

ioi=visited2 .net 
From: 

To: <tel: +1-237- 555 -2222 >;tag=314159 
Call-ID: 
Cseq: 

Require: lOOrel 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Rseq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987332299 IN IP6 8888 :: 111 : 222 : 333 : 446 

s = - 

C=IN IP6 8888 : :111:222 :333 :446 

t = 

m=video RTP/AVP 98 99 

m=audio 53261 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des : qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



SDP answer: the IP address and ports are updated to contain the values provided by ATGW. 

15-16. SIP 183 (Session Progress) response (MSC server to SCC AS) - see example in table A.5.2-15 
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Table A.5.2-15: SIP 183 (Session Progress) response (ATCF to SCC AS) 



SIP/2.0 183 Session Progress 

Via: 

Route: sip : atcf 2 . visited2 .net : 7531; Ir; >; <sip : scscf 1 .homel .net ; lr>;g. 3gpp . srvcc me 

Record- Route : <sip:scscfl .homel .net; lr>,<sip:atcf2 . visited2 .net : 7531; Ir; > 

P-Asserted- Identity: <tel:+l-237-555-llll> 

P- Called- Party- ID :tel: <tel : +l-23 7-555-llll> 

P -Charging- Vector : P -Charging- Vector : icid-value="12 34bc98 76e" ; icid-generated- 

at=5555 : :aaa:bbb: ccc :eeee" ;orig-ioi=visited2 .net 
From: 

To: <tel: +1-237- 555 -2222 >;tag=314159 
Call-ID: 
Cseq: 

Require: lOOrel 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Rseq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987332299 IN IP6 8888 :: 111 : 222 : 333 : 446 

s = - 

C=IN IP6 8888 : :111:222 :333 :446 

t = 

m=video RTP/AVP 98 99 

m=audio 53261 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des : qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



SDP answer: the IP address and ports are the values provided by ATGW. 
16-17. SIP 183 (Session Progress) response (SCC AS to remote UE) 

The SCC AS sends the SIP 183 (Session Progress) response towards the remote UE. 
Regular call setup continues. 

A.6 Signalling flows for PS-CS access transfer 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 
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Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip :pcscfl .homel .net : 7531; Ir >, <sip :orig@scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr= urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 
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NOTE: Steps 20-21 are performed only if signalling over CS domain is possible after the CS-PS access transfer is 
completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalling between the SC UE A and the network. 

23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 

A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capability. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 
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2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 

3. CC SETUP messages 

The SC UE sends the CC SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted- Identity: <tel: +l-237-555-llll> 

P-Charging-Vector: #### 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel: +l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip :mgcf 1 .homel .net ;gr>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 

8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 

Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b99:c88:d7 7:e66] ; ccf= [5555: :a55 :b44 :c3 3 :d22] ; 
ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 

P-Charging-Vector : icid-value="BzyretyU0dm+6O2IrT5tAFrbHLso=023551034" ; orig- 
ioi="type3homel .net" 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=569812 

To: <tel:+l-237-555-2222>; tag=26545 

Call -ID: ddl3aOs0 9a2sdfglkj 490378 

Cseq: 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type: Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. CC CONNECT message (interworking entities to SC UE A) 

17. CC CONNECT ACKNOWLEDGE message (SC UE A to interworking entities) 
18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 22-23 are performed only if SC UE A is using Gm after the PS-CS access transfer is completed; 
otherwise, the SC UE A and the network release the source access leg locally, without any signalling 
between the SC UE A and the network. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS access transfer 
A. 7.1 Introduction 

The signalling flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 7. 2 shows an example when all media of an ongoing communication session and the associated 
signalling are transferred from Source Access Leg to the Target Access Leg; and 

subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 

A. 7. 2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A. 7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or 
needed. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP-CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP-CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP -CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IM CN subsystem support simultaneous multiple 
registrations and requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call lej 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The 
UE- 1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard multiple registrations procedure. 
Depending on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN can precede this. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP -CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP -CAN. The UE-1 reserves resources (e.g. QoS) in the new IP -CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends an initial SIP INVITE request with the PS to PS STI and a new SDP offer to the UE-2 that 
indicates that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for 
signalling and specifies in the SDP the new contact address that will be used for media over the new IP-CAN. 
Upon sending the initial SIP INVITE request, the UE-1 is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets can arrive over the new IP-CAN prior to the UE-1 receiving the 
SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE sip ipstops . transf erOsccasl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl®homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip :pstops . transf erOsccasl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj49033 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Require: sec-agree; replaces 

Replaces: me03aOs09a2sdfgjkl491777; to-tag=774321; f rom-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 ; 

ob>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 
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Require: the "replaces" option tag indicate that the support for Replace header field is required. 

Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP-CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The P-CSCF added a Record-Route header field with a flow token to ensure that mid-dialog SIP 
requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 
3GPP TS 24.229 [2]. The SCC AS includes the contents of the Contact header field from the received SIP 
INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE sip ipstops . transf erOsccasl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . O/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 
Route : <sip:sccas .homel .net; lr>; <sip : Cb03a0s0 9a2sdfglkj4 90333@scscf 1 .homel .net; lr>;orig- 

dialog-id= "0:73 935718^92 645110- 712 78Gjd24 63 953 02d-zKE" 
Record-Route: <sip : scscf 1 .homel .net ; lr>, <sip: 

GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV®pcscfl. homel. net ;lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
P -Access -Network- Info : Privacy : Require : replaces 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 

ioi=type3ashomel .net> 
P-Charging-Function-Addresses : #### 
From: <sip :userl_publicl@homel .net>; tag=171828 
To: <sip :pstops . transferOsccasl .homel .net > 
Call-ID: 
Cseq: 

Supported: 
Replaces : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 
P-Early-Media : supported 



t=0 

m= 

b= 

a= 

a= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header field correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 
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9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 

The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max-Forwards: S7 

Route : <scscf 1 .homel .net; lr>,<sip:scscf2 .home2 .net; lr>,<sip:pcscf2 . visited2 .net; lr> 

P-Asserted- Identity : P- Access -Network- Info : Privacy: P- Charging- Vector: icid- 
value="BzyretyU0dm+602IrT5tAFrbHLso=02 3 551034 " 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: 

Contact : < sip :userl_publicl@homel .net ;gr=urn: uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;ob>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: Accept: application/sdp 

Content-Type : 

Content-Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad895 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP sccas.homel.net; 
branch=z9hG4bK332b33.3; 

Max-Forwards: 66 

Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 

P-Asserted- Identity : 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: Supported: Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Contact : 

Allow: 

Accept : 

Content-TypeContent-Length : 

v= 
o= 



11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP -CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-C/VN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP -CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 

2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has 
received in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP -CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing media on the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP -CAN. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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Since both the old contact address and the new contact address were registered using muhiple registrations procedure 
with different reg-id values, then upon transferring the dialog from the old contact address to the new contact address, 
the UE-1 is still registered with the old contact address and the UE-1 subscription dialog to its reg-event using the old 
contact address is intact. 

A. 7. 3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the access transfer is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP-CAN, obtaining an additional IP address, discovering a P-CSCF, and performing registration in the IM CN 
subsystem, UE-1 reserves resources in the new IP -CAN prior to initiating the PS-PS access transfer procedure. When 
the PS-PS access transfer procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old 
and the new IP-CANs. In this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the 
same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IM CN subsystem support simultaneous multiple registrations 
and requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. UE-1 and UE-2 exchange media over the IP -CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 

2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP-CAN #2 using the standard multiple registrations procedure. The P- 
CSCF in the signalling path of this registration can be distinct from the one used in the signalling path over IP- 
CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP -CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP -CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with the PS to PS STI and a new SDP offer to UE-2 and indicates that 
the video component is to be transferred to IP -CAN #2. The initial SIP INVITE request establishes a dialog for 
signalling and specifies in the SDP new contact address that will be used for media over IP -CAN #2. Upon 
sending the initial SIP INVITE request, UE-1 is ready to receive the RTP packets over both IP -CAN #1 and IP- 
CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE sip :pstops . transf erOsccasl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To : <sip :pstops . transf erOsccasl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Require: sec-agree; tdialog 

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;ob>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 
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Target-Dialog: specifies the existing call that will be transferred. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The P-CSCF added a Record-Route header with a fiow token to ensure that mid-dialog SIP 
requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 

3GPPTS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header field, the SCC AS correlates the SIP INVITE request for 
session transfer to the existing local and remote call legs of the existing concatenated end to end session between 
UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the remote UE- 
2 containing the new SDP offer based on the partial media transfer request received from UE-1 and the 
negotiated SDP for the original session. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in 
the initial SIP INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entitles) 



INVITE < sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 .homel .net ; lr>, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip:userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-212-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50 13333 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;ob>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

= 2987933100 2987933101 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = - 

t = 

m=audio 3456 RTP/AVP 97 96 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

b=AS:25 .4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 

subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer immediately. 

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 can receive some out-of-sequence 
video RTP packets over IP -CAN #1. The video RTP packets are delivered to the codec in sequence. Once UE-1 
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determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers in the RTP 
headers), it can relinquish the resources that it has been using for incoming video media on IP-CAN #1 . 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP -CAN #1. 

Resources used for signalling on IP -CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 

SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1 , 

SIP/2 .0/UDP scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, 

SIP/2 .0/UDP sccas.homel.net;branch=z9hG4bK332b33 .3 
Record- Route : <sip ipcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=1717777 
To: <tel:+l-212-555-2222>;tag=4 321 
Call -ID: dcl4bltl0b3teghmlk5 013333 
CSeq: 111 INVITE 
Supported: precondition, lOOrel 
Contact : <sip :user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 950e-4 8a5-4a74-8d99- 

ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa :bbb 

s = - 

c=IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxptime : 20 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 
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The sec AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) 
response to the initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC 
AS has received in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 . 0/UDP pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , 
SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 135 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip : 
GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@pcscfl .homel .net ; lr> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip :pstops . transf erOsccasl .homel .net>; tag=8 09 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Contact : < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 

Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP -CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 

Max-Forwards: 70 

Route: sip:XopDDDsn0oFFFXRdV9BAXpT3coNuiGKV@pcscf 1 .homel .net : 8 76 5 ; Ir ; comp=sigcomp> , 
<sip:orig(ascscf 1 .homel .net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=64727891 

To: <tel:+l-212-555-2222>; tag=774321 

Call -ID: me0 3a0s0 9a2sdfgjkl4 91777 

Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 

Require: sec -agree; 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;ob>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa : bbb : ccc : eee 

s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response 
to the SIP re-lNVlTE request to the intermediate IM CN subsystem entities, using the content of the Via header 
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field that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents 
of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re- 
INVITE request contains the SDP answer derived from the SDP answer that the SCC AS previously received 
from UE-2 (Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK345b32 .2, 
SIP/2 . 0/UDP pcscf 1 .homel .net ;branch=z9hG4bK568f 35 . 1 , 
SIP/2 . 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 

Record-Route : <sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip : 
XopDDDsn0oFFFXRdV9BAXpT3coNuiGKV(apcscf 1 .homel .net ; lr> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=64727891 

To: <tel:+l-212-555-2222>;tag=774321 

Call -ID: me0 3a0s0 9a2sdfgjkl4 91777 

Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; 

Content-Type : application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa :bbb 

s = - 

c=IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio S544 RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

A. 7. 4 PS-PS Access Transfer with full media transfer for an 
outgoing call in alerting phase 

The signalling flows shown in figure A. 7. 4-1 describes the PS-to-PS access transfer procedure when an early dialog 
originated by the SC UE A, is transferred from one contact address of a SC UE A (using an old IP-CAN) to a different 
contact address of the same SC UE A (using a different IP-CAN). In this example flow, the SC UE A is attached to old 
IP-CAN, and is in the process of establishing a dialog on its Source Access Leg via this IP-CAN, with the UE B. While 
the dialog on the Source Access Leg is in the alerting phase, the SC UE A decides (e.g. based on the measurement 
reports) to transfer this dialog to the Target Access Leg that will be established over the new IP -CAN. Both, the SCC 
AS and the SC UA A support the PS-to-PS access transfer for the dialogs in early dialog phase. 

NOTE 1 : This scenario requires that the SC UE A supports dual mode operation and multiple registration 
procedure. 
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NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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Figure A.7.4-1 : Signalling flow for an outgoing call in the alert phase 

1. SC UE A has sent an INVITE request and subsequently has received a 180 (Ringing) response and it is 
ringing 
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The SC UE A initiated call toward the UE B by sending an initial SIP INVITE request on the Source Access 
Leg, and subsequently it has received a 180 (Ringing) response, and it is providing ring-back. The call has been 
anchored at the SCC AS of the SC UE A. 

The dialog on the Source Access Leg is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From 
tag=64727891", and "To tag=774321". 

2. SC UE A attaches to different IP-CAN 

The SC UE A determines that a handover of the dialog on the Source Access Leg to a Target Access Leg is 
required while this dialog is in the alerting phase. The SC UE A connects to different IP-CAN and obtains a new 
IP address that it will use for the subsequent signalling and media. The SC UE A registers with the S-CSCF over 
the new IP-CAN using the standard multiple registration procedure. If needed, prior to sending the initial SIP 
INVITE request over the new IP -CAN, the SC UE A reserves resources in the new IP-CAN that will be needed 
for the signalling and the media. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.7.5-3 

The SC UE A sends an initial SIP INVITE request over the new IP-CAN with a new SDP offer to the UE B that 
indicates that the new dialog on the Target Access Leg will replace the existing dialog on the Source Access 
Leg. The SDP offer in the initial SIP INVITE request sent on the Target Access Leg specifies the new contact 
address on the new IP-CAN that will be used for the media. 

Table A.7.5-3: SIP INVITE request (SC UE A to intermediate IIVI CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Require: sec-agree; replaces 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; f rom-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5-00a0c91e6bf 6 ; 

ob>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: the tel-URI of the destination, i.e. the UE-B. 

Require: the "replaces" option tag indicate that the support for Replace header field is required. 

Replaces: identifies the dialog on the Source Access that will be replaced with the new dialog on the Target 
Access Leg. 
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SDP: specifies the new IP address for media that the SC UE A has acquired in the new IP-CAN, and also 
indicates that the resources in the new IP-CAN have been acquired. 

4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 

Based on the initial filter criteria in the S-CSCF, the initial SIP INVITE request is routed towards the SCC AS. 

4a Remote Leg Update 

The SCC AS correlates the initial SIP INVITE request received on the Target Access Leg to the dialog on the 
Source Access Leg and to the remote call leg. The SCC AS acting as a B2BUA generates a SIP UPDATE 
request, based on the information in the initial SIP INVITE request received on the Target Access Leg, and the 
information previously stored against these dialogs. The SIP UPDATE request contains the SDP offer that is 
identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the SC UE A on the 
Target Access Leg. 

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS performs the remote call leg update by sending the SIP UPDATE request towards the UE B. 

6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to the remote UE B. 

7. SIP 200 (OK) response (UE B to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer, the remote UE B sends a SIP 200 (OK) 
response. The SIP 200 (OK) response contains the SDP answer. The SDP answer indicates that the resources are 
available. 

8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) response on the Target Access Leg that contains the SDP answer as 
received from the remote UE B. The SDP answer indicates that the resources at the UE B are available. 

10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to SC UE A) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the SC UE A. 

11. SIP PRACK request (SC UE A to Intermediate IM CN subsystem entities) 
The SC UE A acknowledges the receipt of the 183 Session Progress response. 

12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 
The SCC AS acknowledges the receipt of the PRACK request. 

14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SC UE A. Upon 
successful exchange of the SIP 183 (Session Progress) response and the PRACK request on the Target Access 
Leg, the early dialog and associated media has been transferred from the Source Access Leg to the Target Access 
Leg. Since the resources for media on the Source Access Leg are not used any more, the SC UE A releases the 
resources that the SC UE A was using for media on the Source Access Leg. In spite of releasing the resources, 
the early dialog on the Source Access Leg is still in the alerting phase. 

NOTE 4: For clarity, the exchange of the SIP messages and associated SDPs on the Source Access Leg, to release 
the resources that the SC UE A was using for media on the Source Access Leg, is not shown in the 
signalling flow. 
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15. Remote user answers the call 

16. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

The UE B accepts the call and sends 200 (OK) response to the initial INVITE request received from the SC UE 
A.. 

17. 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The 200 (OK) response is forwarded to the SCC AS. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates the 200 (OK) response to initial SIP INVITE request that it has 
received on the Target Access Leg , that indicate that the remote UE B has accepted the call. 

19. 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A) 

The 200 (OK) response is forwarded to the SC UE A. 

20. SIP ACK request (SC UE A to intermediate IM CN subsystem entities) 

The SC UE A acknowledges the SIP 200 (OK) response received from the SCC AS 

21. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

22. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the SIP 200 (OK) response received from the UE B. 
23 SIP ACK request (Intermediate IM CN subsystem entities to UE B) 

The SIP ACK request is forwarded towards the UE B. 
24-31 CANCEL Processing 

The SC UE A cancels the SIP INVITE request sent on the Source Access Leg towards the SCC AS. 

A. 7. 5 PS-PS Access Transfer with full media transfer for an 
incoming call in alerting phase 

The signalling flows shown in the figure A.7.5-1 describes the PS-to-PS access transfer procedure when an incoming 
dialog that is in alerting phase is transferred from one contact address of the SC UE A (using the old IP-CAN) to a 
different contact address of the same SC UE A (using a different IP-CAN). In this example flow the SC UE A has an 
incoming dialog which is anchored at the SCC AS. While the dialog on the Source Access Leg (using the old IP -CAN) 
is in the alerting phase, the SC UE A decides (e.g. based on the measurement reports) to transfer this dialog to the 
Target Access Leg that will be established over the new IP -CAN. The the SCC AS and SC UA A support the PS-to-PS 
access transfer for the dialogs in early dialog phase. 

NOTE 1 : This scenario requires that the SC UE A supports dual mode operation and multiple registration 
procedure. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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Figure A.7.5-1 : Signalling flow for an incoming dialog in the alert phase 

1. SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of the SC UE A. If needed, both ends have reserved the 
resources, and the SC UE A has sent a 180 (Ringing) response to the initial SIP INVITE request received on the 
Source Access Leg. 
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The dialog on the Source Access Leg is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From 
tag=64727891", and "To tag=77432r'. 

2. SC UE A attaches to different IP-CAN 

The SC UE A determines that a handover of the dialog on the Source Access Leg to a Target Access Leg is 
required while this dialog is in the alerting phase. The SC UE A connects to different IP-CAN and obtains new 
IP address that it will use for the subsequent signalling and media. The SC UE A registers with the S-CSCF over 
the new IP-CAN using the standard multiple registration procedure. If needed, prior to sending the initial SIP 
INVITE request over the new IP-CAN, the SC UE A reserves resources in the new IP-CAN that will be needed 
for the signalling and media. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.7.5-3 

The SC UE A sends an initial SIP INVITE request on the Target Access Leg with a new SDP offer toward the 
UE B and indicates that the new dialog on the Target Access Leg will replace the existing early dialog on the 
Source Access Leg. The SDP offer in the initial SIP INVITE request sent on the Target Access Leg specifies the 
new contact address that will be used for the media over the new IP-CAN. 

Table A.7.5-3: SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Require: sec-agree; replaces 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; f rom-tag=S4727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 ; 

ob>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: the tel-URI of the destination, i.e. the UE-B. 

Require: the "replaces" option tag indicate that the support for Replace header field is required. 

Replaces: that identifies the dialog on the Source Access Leg that will be replaced with the new dialog on the 

Target Access Leg. 

SDP: specifies the new IP address for media that the SC UE A has acquired in the new IP-CAN, and also 
indicates that the resources in the new IP-C/VN have been acquired. 

4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 
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Based on the initial filter criteria in the S-CSCF, the initial SIP INVITE request is routed towards the SCC AS. 

4a. Remote Leg Update 

The SCC AS correlates the initial SIP INVITE request received on the Target Access Leg to the dialog on the 
Source Access Leg, and to the remote call leg. The SCC AS acting as a B2BUA generates a SIP UPDATE 
request, based on the information received in the initial SIP INVITE request on the Target Access Leg, and the 
information previously stored against these dialogs. The SIP UPDATE request contains the SDP offer that is 
identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the SC UE A on the 
Target Access Leg. 

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS performs the remote call leg update by sending the SIP UPDATE request towards the UE B. 

6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to the remote UE B. 

7. SIP 200 (OK) response (UE B to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer, the remote UE B sends a SIP 200 (OK) 
response. The SIP 200 (OK) response contains the SDP answer. The SDP answer indicates that the resources are 
available. 

8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) response on the Target Access Leg that contains the SDP answer as 
received from the remote UE B. The SDP answer indicates that resources are available. The SIP 183 (Session 
Progress) response will contain a Recv-Info header field set to g.3gpp.state-and-event. 

10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to SC UE A) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the SC UE A. 

11. SIP PRACK request (SC UE A to Intermediate IM CN subsystem entities) 
The SC UE A acknowledges the receipt of the 183 (Session Progress) response. 

12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 
The SCC AS acknowledges the PRACK request. 

14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SC UE A. Upon 
successful exchange of the SIP 183 (Session Progress) response and the PRACK request on the Target Access 
Leg, the early dialog and associated media has been transferred from the Source Access Leg to the Target Access 
Leg. Since the resources for media on the Source Access Leg are not used any more, the SC UE A releases the 
resources that the SC UE A was using for media on the Source Access Leg. In spite of releasing the resources, 
the early dialog on the Source Access Leg is still in the alerting phase. 

NOTE 4: For clarity, the exchange of the SIP messages and associated SDPs on the Source Access Leg, to release 
the resources that the SC UE A was using for media on the Source Access Leg, is not shown in the 
signalling flow. 

15. User answers the call 
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16. The SC UE A accepts the call and sends SIP INFO request to intermediate IM CN subsystem entities see 
example in table A.7.5-16 

The SC UE sends a SIP INFO request that indicates that the call has been accepted. 
Table A.7.5-16: SIP INFO request (SC UE A to intermediate IM CN subsystem entities) 



INFO tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel:+l-212-555-2222>;tag=17182 8 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 130 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info 

< event >call- accept ed< /event > 
< /state- and- event -info> 



17. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets 
informed that the SC UE A has accepted the call. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the 
call. 

19. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A) 

The SIP 200 (OK) response is forwarded to the SC UE A. 

20. SCC AS completes the SIP procedure on all three call-legs 

The SCC AS generates a SIP 200 (OK) response toward the UE B, a SIP 200 (OK) response toward the UE A on 
the Target Access Leg, and a CANCEL request toward the UE A on the Source Access Leg. 

21. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to UE B that indicates that the SC UE A has accepted the call. 

22. SIP 200 (OK) response (Intermediate IM CN subsystem entities to the UE B) 
The SIP 200 (OK) response is forwarded to the UE B. 

23. SIP ACK request (UE B to intermediate IM CN subsystem entities) 

The remote UE B acknowledges the SIP 200 (OK) response received from SCC AS by sending a SIP ACK 
request. 

24. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 

The SIP ACK request is forwarded to the SCC AS. 

25. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to the SC UE A on the Target Access Leg to indicate the successful 
access transfer. 

26. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A) 

The SIP 200 (OK) response is forwarded to the SC UE A. 
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27. SIP ACK request (SC UE A to intermediate IM CN subsystem entities) 

SC UE A acknowledges the receipt of the 200 (OK) response received on the Target Access Leg from SCC AS 
by sending a SIP ACK request. 

28. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 

The SIP ACK request is forwarded to the SCC AS. 
29-36 CANCEL Processing 

The SCC AS cancels the early dialog on the Source Access Leg. 



A. 8 Signalling flows for PS-PS access transfer in 
conjunction with PS-CS access transfer 

A. 8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 8. 2 shows an example when a multimedia session is transferred from one IP-CAN to a new IP -CAN 
and the CS bearer respectively ; and 

subclause A. 8. 3 shows an example when a multimedia session is transferred from one IP -CAN and CS bearer to 
a new IP -CAN. 

A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 

Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP -CAN and CS bearer, only the SDP offer is 
shown in table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security-Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP -CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP-CAN can be needed. Based on the UE A and new IP -CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP -CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP -CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving the 
SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip:orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Target -Dialog :me0 3a0s0 9a2sdfgjkl4 91777; to-tag=774 321; f rom-tag=64 72 78 91 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 

s = 

t = 

m=audio RTP/AVP 97 96 

c=IN IP6 5555 :: aaa: bbb: ccc :ddd 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

a=accept-types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
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request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74>; SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 
P-Charging-Vector: #### 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-237-555-2222>, tag=4321 
Call-ID: dcl4bltl0b3teghmlk5013237 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96 
c=IN IP6 5555 :: aaa: bbb: CCC: ddd 
b=AS:2 5.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 20 

m=message 7654 TCP/MSRP 98 
c=IN IP6 5555: : aaa :bbb:ccc:fff 
a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. CC SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CC SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector: #### 

Privacy: none 

From: <tel: +l-237-555-llll> ; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : <sip :mgcf 2 .home2 .net ;gr>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 

23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
field from the received SIP INVITE request. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IIVI CN subsystem entities) 



INVITE < sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 
P-Asserted-Identity: <tel: +l-237-555-llll> 
P-Charging-Function-Addresses : #### 
P-Charging-Vector: #### 
Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 
To: <tel:+l-237-555-2222>; tag=26545 
Call -ID: Cb03a0s09a2sdfglkj49033 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 
Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

t = 

m=audio 3456 RTP/AVP 97 96 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

c=IN IP6 5555: : aaa :bbb:ccc:fff 

a=accept-types : text/plain 



24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. CC CONNECT message (interworking entities to SC UE A) 

32. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to interworking entities) 
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33-34. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UEA. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE SIP request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP -CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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1 . SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 
Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the reahime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN can precede this. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets can arrive over the new IP -CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : sip ipcscf 1 .homel .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 

Require: sec-agree, replaces 

Proxy-Require: sec-agree 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl®homel .net ;gr= urn:uuid: f81d4fae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g . 3gpp- icsi-ref ="urn%3Aurn-xxx%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321 ; f rom-tag=64727891 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:User2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=569812 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91eGbf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 
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The sec AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP -CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

24-25. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 

28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting for access 
transfer 

A.9.1 Introduction 

The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

subclause A.9. 2 shows an example when the non-realtime media of a multimedia session over the IP -CAN is 
removed. 

A. 9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote UE after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 
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Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS 

sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P- Asserted- Identity: 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security- Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 
P-Asserted-Identity: <tel: +l-237-555-2222> 
P-Charging-Function-Addresses : #### 
P-Charging-Vector: #### 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-237-555-2222; gr=hdg7777ad7af IzigSsf 7> ; tag=171828 
To: <tel:+l-237-555-llll> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 
Contact : < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad895 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



3. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP-CAN, by sending a SIP BYE request to the 
UEA. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the IP-C/VN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequendy, the SC UE A relinquishes all resources pertaining to the IP-C/VN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 
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A. 10 Void 

A.11 Void 

A. 12 Void 

A. 13 Void 

A. 14 Void 

A.I 5 Signalling flows for MSC server assisted mid-call 
feature 

A.I 5.1 Introduction 

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with 
active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are 
included: 

subclause A. 15.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature. 

subclause A. 15.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature. 

subclause A. 15.4 shows an example of PS to CS access transfer with MSC server assisted mid-call feature with 
an incoming waiting call in alerting phase 

The examples assume that: 

the SC UE, the MSC server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature; 

the SC UE does not use ICS procedures; and 

the SCC AS is allowed to use the MSC server assisted mid-call feature according to operator policy. 

A.1 5.2 CS to PS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 15.2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at 
SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two 
party sessions. The session Y contains rejected video stream and accepted speech media component. When the SC UE 
connects to an IP-CAN, it decides to transfer the sessions over the IP -CAN. 
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1. SC UE A is on an active session X with UE B and held session Y with UE C. Both calls are anchored at 
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Figure A.15.2-1 : Signalling flow for PS-CS Access Transfer: CS to PS 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing active session X with remote UE B and a held session Y with remote UE C 
The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the sessions over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem 
entities) - see example in table A.15.2-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call X. 
Table A.15.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : <sip ipcscf 1 .homel .net :7531;lr>, <sip lorigOscscf 1 .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 
To: <tel:+l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4 902 3 7 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu, norefersub 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 
Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6> ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml, application/vnd. 3gpp .mid-call+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 
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The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A (Step 3). 

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The media path of session X is using the new IP-CAN but the media path of the session Y is still using the CS 
bearer. 

18-19. SIP BYE request (SCC AS to MSC Server via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

NOTE: Steps 20-22 are performed only if signalling over CS domain is possible after the CS-PS access transfer is 
completed; otherwise, the SC UE A and the network release the source access leg of session X locally, 
without any signalling between the SC UE and the network. 

23-24. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP -CAN, the MSC Server sends a SIP 200 (OK) response over 
the old IP-CAN to the SCC AS. 

25: SIP REFER request (SCC AS to Intermediate IM CN subsystem entities) -see example in table A.15.2-25 

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13. 
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Table A.15.2-25: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 SIP/2 . 

Via: SIP/2. 0/UDP sip: sccasl .homel .net;branch=z9hG4bk731b8a 

Max-Forwards: 70 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

From: <tel : +l-237-555-2222>; tag=aasdf gaag 

To: <sip :userl_publicl@homel .net>; tag=171828 

Call -ID: Cb03a0s0 9a2sdfglkj 490237 

Cseq: 55998 REFER 

Content-Length: . . . 

Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net:7531;lr> 

Contact : <sip : sccasl .homel .net ;gr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Ref er-To : <sip : additional . session.xf erOsccas .homel . net ?Target-Dialog=a84b4c76e6 6 710 %3Bremote - 
tag=654364735%3Blocal-tag=192 83 01774&Require=tdialog&From=tel: +1-23 7-555 -llll&To=tel:+l - 
9B7-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 623 %2 02 987933 623 %2 0IN%2 0IP6%2 05555: :ggg : f f f : aaa :bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IP6%205555 : :ggg:fff :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%2 0AMR%0D 
%0Aa%3Dfmtp:97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A> 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<mid-call/> 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 

Target-Dialog: the dialog identifier of the source access leg. 

Require: containing "tdialog" option tag 

From: contains the public user identity of the UE A 

To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

26. SIP REFER request (intermediate IM CN subsystem entities to UE A) 

The SIP REFER request is forwarded towards the UE A. 

27-28. SIP 202 (Accepted) response (UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the UE A sends a SIP 202 (Accepted) response. 

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) 
- see example in table A. 15.2-29 

The SC UE A sends an initial SIP INVITE request to request the new call replacing the existing call Y. 
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Table A.15.2-29: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : additional . session. xferOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net :7531;lr>, <sip :orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <tel:+l-237-555-llll>; tag=171828 
To: <tel:+l-987-654-3210> 
Call-ID: asdfqweasas 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 
Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6> ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 

Target -Dialog: a84b4c7Se6S710 /remote- tag=654364735 ; local- tag=19283 01774 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos loca 

a=tcap:l RTP/AVPF 

a=pcfg:l t=ll sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: All the media are offered with the sendonly directionality. 

30. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

31. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

32. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

33. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
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contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A. 

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 
35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate IM CN subsystem entities) 

The UE C generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
37-38: SIP ACK request (SCC AS to UE C via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE C. 
39: SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
40: SIP 200 (OK) response (Intermediate IM CN subsystem entities to UE A) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
41-42: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
43. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP -CAN but the the CS bearer is still not released. 
44-45. SIP BYE request (SCC AS to MSC Server via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

46-48. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

NOTE: Steps 46-48 are performed only if signalling over CS domain is possible after the CS-PS access transfer is 
completed; otherwise, the SC UE and the network release the source access leg of session Y locally, 
without any signalling between the SC UE and the network. 

49-50. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

51. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP-CAN. 

A.1 5.3 PS to CS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 15.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at 
SCC AS. When both sessions were established the SC UE and the SCC AS included the g.3gpp. mid-call media feature 
tag as specified in annex C into the Contact header fields. The active session X is with UE B, the held session Y is with 
UE C. The session X and session Y are two party sessions. The session Y contains a rejected video stream and an 
accepted speech media component. When the SC UE attaches to the CS domain, it decides to transfer the sessions over 
the CS bearer without using the ICS capability. 
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Figure A.15.3-1 : Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session X with UE B and a held session Y with UE C: 

There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer. 

3. CC SETUP messages 
Transaction Identifier: 3 
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4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem 
entities) -see example in table A.15.3-4 

Upon receiving the CC SETUP message the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 3 with the SIP INVITE request. 

Table A.15.3-4: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . homel . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

P- Asserted- Identity: <tel : +1-237- 555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199, norefersub 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service. ims .icsi .mmtel 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6> ; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" ; +g. 3gpp. mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

Accept: application/sdp; application/3gpp-ims+xml, application/vnd. 3gpp .mid-call+xml 

Recv-Info: g. 3gpp .mid-call 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 

SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. 

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 
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The sec AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 

9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to MSC Server via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

16. CC CONNECT message (MSC Server to SC UE A) 

17. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to MSC Server) 

18-19. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 
20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearers are still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session X, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 22-23 are performed only if SC UE A is using Gm after the PS-CS access transfer is completed; 
otherwise, the SC UE A and the network release the source access leg of session X locally, without any 
signalling between the SC UE A and the network. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.3-26 

The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14. 
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Table A.15.3-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip:userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 SIP/2 . 

Via: SIP/2. 0/UDP sip: sccasl .homel .net;branch=z9hG4bk731b8a 

Max-Forwards: 70 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

To: <tel: +1-237- 555 -llll>;tag=171828 

From: <tel: +1-237- 555- 3333 >;tag=sdfsdf 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl .homel .net 

Ref er-To : < additional . session.xf erOsccas .homel .net?Target-Dialog=ksdj fhwrklf %3Bremote- 
tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +1-987- 
654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 623 %2 02 987933 623 %2 0IN%2 0IP6%2 05555: :ggg : f f f : aaa :bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IP6%205555 : :ggg:fff :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%2 0AMR%0D 
%0Aa%3Dfmtp:97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A> 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<mid-call/> 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 

Target-Dialog: the dialog identifier of the source access leg. 

Require: containing "tdialog" option tag 

From: contains the public user identity of the UE A 

To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

27. SIP REFER request (intermediate IM CN subsystem entities to MSC Server) 

The SIP REFER request is forwarded towards the MSC Server. 

28-29. SIP 202 (Accepted) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC Server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see 
example in table A.15.3-30 

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 4 with the SIP INVITE request. 
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Table A.1 5.3-30: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE 

sip : additional . session.xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP mscl. homel. net;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel:+l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel:+l-987-654-3210> 

Call-ID: asdfgqwerq 

Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6> ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" ; +g. 3gpp. mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Target -Dialog: ksdj fhwrklf; remote- tag=676723 565 ; local- tag=45418454 

Require : tdialog 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. All the media are offered 
with the sendonly directionality. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

32. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

34. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE C via the 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 249 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

intermediate IM CN subsystem entities. The SIP re-INVITE request contains the SDP offer that is identical to 
the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 

35. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE C has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

38-39. SIP ACK request (SCC AS to UE C via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE C. 

40. SIP 200 (OK) response (SCC AS to IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server) 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC 
Server. 

42-43. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

44. Media paths between SC UE A and UE B: 

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the 
held session Y. 

45-46: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

47-48. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A reUnquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 46-47 are performed only if the SC UE A uses Gm after the PS-CS access transfer is completed; 
otherwise, the SC UE A and the network release the source access leg locally, without any signalling 
between the SC UE A and the network. 

49. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 

A.1 5.4 PS to CS access transfer with MSC server assisted mid-call 
feature with an incoming waiting call in alerting phase 

In the example flow at the figure A. 15.4-1, SC UE A has an ongoing sessions with speech media component and an 
incoming waiting session with speech media component which are anchored at SCC AS. The incoming waiting call is 
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in alerting state. The ongoing session X is with UE B, the incoming waiting session Y is with UE C. The session X and 
session Y are two party sessions. Based upon measurement reports sent from the UE to E-UTRAN, the source E- 
UTRAN decides to trigger a PS to CS SRVCC procedure to CS access. 
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Figure A.15.4-1 : Signalling flow for PS to CS access transfer with MSC server assisted mid-call 
feature with an incoming waiting call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session X with UE B and an incoming waiting session Y with UE C: 

There is an ongoing PS bearer between the SC UE and the remote UE B and another PS bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A sends the measurement reports to E-UTRAN 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPPTS 23.237 [9]. 

3-24. Access transfer for the active session X 

The procedure for transfering the active session X is the same as step 4 to step 15 and step 18 to step 24 
described in subclause A. 15.3. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.4-26 

The SCC AS sends SIP REFER request towards MSC server inside the dialog created by the the message 14, 
and it also contain the state-and-event-info XML body to indicate that the additional session is an incoming 
session in alerting phase. 
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Table A.15.4-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 SIP/2 . 

Via: SIP/2. 0/UDP sip: sccasl .homel .net;branch=z9hG4bk731b8a 

Max-Forwards: 70 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

To: <tel: +1-237- 555 -llll>;tag=171828 

From: <tel: +1-237- 555- 3333 >;tag=sdfsdf 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl .homel .net 

Ref er-To : < additional . session.xf erOsccas .homel .net?Target-Dialog=ksdj fhwrklf %3Bremote- 
tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +1-987- 
654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 623 %2 02 987933 £23 %2 0IN%2 0IP6%2 05555: :ggg : f f f : aaa :bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IPe%205555 : :ggg:fff :aaa:bbb%0D%0At%3D0%2 0%0D%0Aaudio%2 0345 6%2 0RTP%2FAVP%2 9 
7%2 096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%2 0AMR%0D%0Aa%3Dfmtp:97%2 0mode- 
set%3D0%2C2%2C5%2C7%3B%2 0mode-change-period%3D2%0D%0Aa%3Dmaxptime:2 0%0D%0A> 

Content-Type: boundary=boundaryl 

--boundaryl 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mid-call/> 

--boundaryl 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< state- info>early</ state -info> 

<direction>receiver</direction> 
< /state- and- event -info> 

- -boundary- - 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 

Target-Dialog: the dialog identifier of the source access leg. 

Require: containing "tdialog" option tag 

From: contains the public user identity of the UE A 

To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session. 

XML Schema: contain the session state information that the additional session is an incoming session in 
alerting state. 

27. SIP REFER request (intermediate IM CN subsystem entities to MSC server) 

The SIP REFER request is forwarded towards the MSC server. 

28-29. SIP 202 (Accepted) response (MSC server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC server to Intermediate IM CN subsystem entities) -see 
example in table A.15.4-30 

Upon receiving the SIP REFER request which contain the session state information to indicate that the additional 
session in an incoming session in alerting state, the MSC server moves to Call Received state as described in the 
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SIP REFER request but does not generate an in-band ring tone to the calling party, and sends a SIP INVITE 
request and associates the transaction identifier with the SIP INVITE request. 

Table A.15.4-30: SIP INVITE request (MSC server to intermediate IM CN subsystem entities) 



INVITE 

sip : additional . session.xf erOsccas .homel .net SIP/2.0 
Via: SIP/2. 0/UDP mscl. homel. net;branch=z9hG4bk731b87 
Max- Forwards : 70 

P- Asserted- Identity: <tel : +l-23 7-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 
To: <tel:+l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 
Contact : <sip :mscl@homel .net> ;+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" ; +g. 3gpp. mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 

Target -Dialog: ksdj fhwrklf; remote- tag=676723 565 ; local- tag=45418454 
Require : tdialog 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSC server. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

32. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

34. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP UPDATE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE C via the 
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intermediate IM CN subsystem entities. The SIP UPDATE request contains the SDP offer that is identical to the 
SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 

35. SIP UPDATE request (Intermediate IM CN subsystem entities to UE C) 

Intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer, since the UE C has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP UPDATE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP UPDATE request to 
the SCC AS in the originating network. 

38-39. SIP 183 (Session Progress) response (SCC AS to MSC server via IM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the UE C. The SDP 
answer indicates that resources are available 

40. SIP PRACK request (MSC Server to Intermediate IM CN subsystem entities) 

The MSC server acknowledges the receipt of the 183 Session Progress. 

41. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem forward the SIP PRACK request to the SCC AS 
42-43. SIP 200 (OK) response (SCC AS to MSC server via IM CN subsystem entities) 
The SCC AS acknowledges the PRACK with a SIP 200 (OK) response to the MSC server. 

44. CC HOLD Message (SC UE to MSC server) 
The SC UE A put the active session on hold. 

45. SIP re-INVITE request (MSC server to intermediate IM CN subsystem entities) 

Upon receiving the CS HOLD Message from the UE, MSC server sends a SIP re-INVITE request towords 
session X, which put session X on hold. The SDP in this SIP re-INVITE request is based on the last SDP 
offer/answer negotiation for the active session transfer form step 3 to 24, but for each media streams set the SDP 
attribute to "sendonly". 

46. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

The SIP re-INVITE request is forwarded to the SCC AS. 

47-48. SIP re-INVITE request (SCC AS to UE B) 

SCC AS sends SIP re-INVITE request to UE B, The SIP re-INVITE request contains the SDP offer that is 
identical to the SDP offer that the SCC AS received in the SIP re-INVITE request from the MSC server. 

49-50. SIP 200 (OK) response (UE B to SCC AS) 

Upon receiving the SIP re-INVITE request containing the SDP offer which contain the SDP attribute for each 
media streams to "sendonly", UE B response the SIP re-INVITE request with a SIP 200 (OK), which set the SDP 
attribute for each media streams to "receonly". 

51-52. SIP ACK request (SCC AS to UE B) 

53-54. SIP 200 (OK) response (SCC AS to MSC server via intermediate IM CN subsystem entities ) 

The SCC AS sends 200 (OK) to indicate the succesfull activity to the MSC server that put session X on hold. 
55. CC HOLD ACKNOWLEDGE Message (MSC server to SC UE A) 
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56-57. SIP ACK request (MSC server to SCC AS via intermediate IM CN subsystem entities) 

MSC server acknowledges the 200 OK received from SCC AS. 

58. CC CONNECT message from SC UE A to MSC server 

The SC UE A accepts the call and sends CC CONNECT message. 

59. SIP INFO request (MSC server to intermediate IM CN subsystem entities) - see example in table A.15.4- 
59 

A.1 5.4-59: INFO (SCC AS to intermediate IM CN subsystem entities) 



INFO sip: sccasl .homel .net;gr SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ;branch=z9hG4bk731b87 

Max- Forwards : 6 8 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel: +1-237- 555- llll>;tag=171828 

To: <tel: +l-237-555-3333>;tag=171828 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 130 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

<event >call - accept ed< /event > 
< /state- and- event -info> 



XML Schema: contain the session state information indicating that the remote party has answered the call. 

60. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets 
informed that the SC UE A has accepted the call. 

61. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the 
call 

62. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The SIP 200 (OK)response is forwarded to the MSC server. 

63. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call. 

64. SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the far end) 

65. SIP ACK request (far end to intermediate IM CN subsystem entities) 

The far end UE acknowledges the SIP 200 (OK) response received from the SCC AS 

66. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

67. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends 200 (OK) response to indicate the succesfull access transfer to the MSC server. 
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68. SIP 200 (OK) response (Intermdeiat IM CN subsystem entities to far end) 

The SIP 200 (OK) response is forwarded to the MSC server. 

69. CC CONNECT ACKNOWLEDGE (MSC server to SC UE A) 

70. SIP ACK request (MSC server to intermediate IM CN subsystem entities) 
MSC server acknowledges the SIP 200 (OK) response received from SCC AS. 

71. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

72-73: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

74-75. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 73-74 are performed only if the SC UE A uses Gm after the PS-CS access transfer is completed; 
otherwise, the SC UE A and the network release the source access leg of session Y locally, without any 
signalhng between the SC UE A and the network. 

76. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 



A.16 Signalling flows for PS to CS SRVCC session 
transfer for IMS emergency session 

A. 16.1 Introduction 

The signalling flows for PS to CS SRVCC session transfer for IMS emergency session demonstrate how an IMS 
emergency session is transferred from PS network to CS network using PS to CS SRVCC procedure. The following 
signalling flow is included: 

subclause A. 16.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE 
is not in limited service mode ;and 

subclause A. 16.3 shows an example when the emergency session need to transfer from PS to CS using PS to CS 
SRVCC procedure for the case that the UE is not in limited service mode. 

A.I 6.2 UE initiating an emergency session in IMS 

The signalling flows shown in figure A.16. 2-1 describes the UE initiating an IMS emergency session procedure for the 
case that the UE is not in limited service mode. The flow illustrates the anchoring of the session at the EATF. 
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Figure A.16.2-1 : Signalling flow for UE initiating an emergency session in IIVIS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
NOTE 2: For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow. 
NOTE 3: For clarity, the precondition mechanism is not shown in the signalling flow. 
1. SIP INVITE request (UE A to P-CSCF) see example in table A.16.2-2 
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Table A.16.2-2: SIP INVITE request 



INVITE urn: service: SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf . visit 1 .net : 7531; lr;comp=sigcomp> 

P -Preferred- Identity : <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <urn: service : SOS . fire> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept : application/sdp, application/3gpp-ims+xml 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +sip. instance="<urn:gsma:imei :90420156-025763-0>" 

Geolocation: <sips : 3sdef rhy2 j j 701 is . atlanta. example . com>; insert ed- 
by=" sip: user l_publicl@homel .net" ; rout ing-allowed=" yes" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3400 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a=inactive 



Contact: contains the "sip. instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed 
from an IMEI as defined in 3GPP TS 23.003 [12]. 

2. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-3 
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Table A.16.2-3: SIP INVITE request 



INVITE urn: service: SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP pcscf . visitl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:ecscf. visitl .net; Ir; > 
Record- Route : <sip: pcscf .visitl .net; lr> 
P -Preferred- Identity : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Require : 
Proxy-Require : 
Accept -Contact : 
P-Pref erred-Service : 
Security-Verify: 
Contact : 
Geolocation: 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 



m= 

a=curr : 
a=curr : 
a=des : 
a=des : 
a= 



3. SIP INVITE request (E-CSCF to EATF) see example in table A.16.2-4 
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Table A.1 6.2-4: SIP INVITE request 



INVITE urn: service: SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas . visitl . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
pcscf . visitl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 68 

Route : <sip:esccas. visitl .net; Ir; > 

Record- Route : <sip:ecscf. visitl .net; lr>,<sip:pcscf.visitl.net;lr> 

P -Preferred- Identity : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Accept : 

Require : 

Proxy-Require : 

Accept-Contact : 

P-Pref erred-Service : 

Security-Verify: 

Contact : 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; inserted- 

by=" sip: user l_publicl(ahomel .net" ; rout ing-allowed=" yes" ; used- for -routing 

Allow: 

Content-Type : 

Content-Length: (...) 



4. EATF anchors the emergency session 

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the 
signalHng path which invokes a 3pcc for enablement of Access Transfers 

5. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-5 

The EATF acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 
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Table A.16.2-5: SIP INVITE request 



INVITE urn: service: SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas . visitl . net ;branch=z9hG4bKnas34r5 

Max-Forwards: 67 

Route : <sip:ecscf. visitl .net : 75 31; lr;comp=sigcomp> 

Record- Route : <sip:ecscf. visitl .net; lr> 

P -Preferred- Identity : <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <urn: service : SOS . fire > 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept : application/sdp, application/3gpp-ims+xml 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +sip. instance="<urn:gsma:imei :90420156-025763-0>" 

Geolocation: <sips : 3sdef rhy2j j 7@lis . atlanta . example . com>; insert ed-by=" 
sip: user l_publicl@homel .net "Crouting-allowed="yes" ; used- for -routing 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a=inactive 



6. SIP INVITE request (E-CSCF to PSAP) 

E-CSCF routes the SIP INVITE request to the PSAP. 

7. SIP 200 (OK) response (PSAP to E-CSCF) see example in table A.16.2-6 

Table A.16.2-6: SIP 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ecscf .visitl . net ;branch=z9hG4bKnas34r5 

Max- Forwards : 6 7 

Record- Route : <sip:ecscf.visitl.net;lr>,<sip:pcscf.visitl.net;lr> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: < urn: service : SOS . fire >;tag=232456 

Call-ID: 

Cseq: 

Require: lOOrel, precondition, 199, gruu 

Contact: <sip :mgcf .visitl .net> . 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = 

c= IN IP6 5555 : :fff :eee:ccc:ddd 

t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 
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8-9. SIP 200 (OK) response (E-CSCF to EATF and to E-CSCF) 

E-CSCF forwards the SIP 200 (OK) response. 
10-11. SIP 200 (OK) response (E-CSCF to UE A) see example in table A.16.2-7 

Table A.16.2-7: SIP 200 (OK) response 



SIP/2.0 200 OK 

Via: 

Max-Forwards: 65 

Record-Route : 

Privacy: 

From: 

To: 

P-Asserted- Identity : tel : 911, • context = "+1" 

Call-ID: 

Cseq: 

Require : 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



12, SIP ACK request 

UE A responds to the 200 (OK) response with a SIP ACK request. 

A.1 6.3 Session transfer for emergency session using PS to CS 
SRVCC procedure: PS-CS 

In the example in figure A. 16. 3-1, UE A (which has a valid subscription, is authenticated and authorized for PS service 
and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is 
anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to 
trigger a PS to CS SRVCC handover to CS access. 
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Figure A.16.3-1 Signalling flow for emergency session transfer using PS to CS SRVCC procedure 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active emergency session with a PSAP 

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC Server initiates the session transfer with the E-STN-SR, refer to 

3GPPTS 23.237 [9]. 

3. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.16.3-2 
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Table A.16.3-2: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 
Max-Forwards: 70 

Route : <sip:icscfl.visitl.net;lr> 
P- Asserted- Identity: <tel : +1-237- 555- 1111> 
P-Charging-Vector: #### 
Privacy: none 

From: <tel: +1-237- 555- llll>;tag=171828 
To: <tel: +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4903 34 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn: urn- 7 :3gpp- service . ims .icsi .mmtel 

Contact : <sip :mscl .homel .net>;+sip . instance="<urn:gsma : imei : 90420156- 025763- 0>";+g. 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Request-URI: contains the E-STN-SR, as routed to the EATF 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Contact: contains the "sip. instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed 
from an IMEI as defined in 3GPP TS 23.003 [12]. 

4. SIP INVITE request 

The I-CSCF routes the SIP INVITE request directly to the EATF by using the procedure defined in 
3GPP TS 23.228 [15] for PSI based application Server termination. 

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 

3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the SIP INVITE request to the EATF. 

5. Remote Leg Update 

The EATF based on the content of the "gr" parameter in the Contact header field correlates the SIP INVITE 
request to the local and remote call legs of the existing session between the UE A and the remote end. The EATF 
performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

6. SIP re-INVITE request (EATF to intermediate IM CN subsystem entities) -see example in table A.16.3-3 

TheEATF acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 

Table A.16.3-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE urn : service :sos. fire SIP/2.0 

Via: SIP/2. 0/UDP esccasl .homel .net, -branch=z9hG4bKnas34r5 
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Max-Forwards: 68 

Route: <sip : ecscf 1 .homel .net : lr> 
P-Asserted-Identity: <tel: +l-237-555-llll> 
P-Charging-Function-Addresses : #### 
P-Charging-Vector:#### 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To : <urn : service : sos . f ire> ; tag=232456 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-Vdec-lldO-aTSS- 
OOaOcSleebf 6>;+sip. instance="<urn:gsma: imei :90420156-025763-0>" 
Allow: 
Content-Type: Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



7. SIP re-INVITE request (E-CSCF to PSAP) 

E-CSCF forward the SIP re-INVITE request to the PSAP. 

8. SIP 200 (OK) response (PSAP to E-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

9. SIP 200 (OK) response (E-CSCF to EATF) 

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating 
network. 

10-11. SIP ACK request (EATF to PSAP via IM CN subsystem entities) 

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to 
the PSAP. 

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities) 

The E- sec AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 
(OK) response to the interworking entities. 

14-15. SIP ACK request (interworking entities to EATF via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK 
request to the EATF. 

16-18: SIP BYE request (EATF to UE A via intermediate IM CN subsystem entities) 

The EATF terminates the source access leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the UE A. 

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities) 
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Upon receiving the SIP BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the 
old IP -CAN to the EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 18-19 are performed only if the UE A uses Gm after the PS-CS access transfer is completed; 

otherwise, the UE A and the network release the source access leg locally, without any signalling between 
the UE A and the network. 

22a. CS bearer establishment (interworking entities to UE A) 

22b. IP bearer establishment (interworking entities to PSAP) 



A. 17 Signalling flows for PS to CS SRVCC in Alerting 
State 

A. 17.1 Introduction 

The signalling flows in the subclause demonstrate how sessions in alerting state can be transferred from PS to CS using 
PS to CS SRVCC procedures. The following signalling flows are included: 

subclause A. 17.2 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase. 

subclause A. 17.3 shows an example of PS to CS SRVCC transfer where the outgoing call is in alerting phase. 

subclause A. 17.4 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase, 
but the user answers the call in the PS domain prior to the completion of the network handover procedures and 
the UE retuning to the CS domain. 

subclause A. 17.5 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase, 
but the user answers the call in the PS domain prior to the completion of the network handover procedures but 
the handover to CS does not succeed. 

subclause A. 17.6 shows an example of PS to CS SRVCC transfer where the outgoing call is in alerting phase and 
the UE has received several forked responses prior to the initiation of access transfer. 

A.I 7.2 Session transfer for incoming call is in alerting phase using 
PS to CS SRVCC procedure: PS to CS 

In the example flow at the figure A. 15.2-1, SC UE A has an incoming session with speech media component which is 
anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, 
the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access. 
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Figure A.1 7.2-1 : PS-CS SRVCC, incoming call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC 
UE A has sent a 180 (Ringing) response. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

3. SIP INVITE request transferring the session (MSC server to intermediate IM CN subsystem entities) - see 
example in table A.17.2-1 

The MSC server sends an initial SIP INVITE request with STN-SR. 

Table A.17.2-1 : SIP INVITE request (IVISC server to intermediate IIUI CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

Route : <sip:icscfl. visitl .net; lr> 

P-Asserted- Identity: <tel : +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555- llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4903 34 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visitl .net : 13 5 7 >; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

+g . 3gpp . srvcc-alerting 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv-Info : g. 3gpp . state -and- event 
Content-Type: application/sdp 
Content-Length: (...) 
P-Early-Media : supported 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 
Contact: contains the +g.3gpp. srvcc-alerting feature tag. 
4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is routed towards the SCC AS, based on filter criteria in S-CSCF. 
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4a. Remote Leg Update 

The sec AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. The SCC AS performs the Remote Leg update by sending the SIP sending a SIP 
UPDATE request towards the Remote Leg. 

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request 
and the information previously stored against this session . 

6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B. 

7. SIP 200 (OK) response (far end UE to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the far end sends a 
SIP 200 (OK) response. 

8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 183 (Session Progress) response containing the SDP answer as received from the far 
end UE B. The SDP answer indicates that resources are available. The SIP 183 (Session Progress) response will 
contain a Recv-Info header field set to g.3gpp.state-and-event. 

10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the MSC server. 

11. SIP PRACK request (MSC server to Intermediate IM CN subsystem entities) 
The MSC acknowledges the receipt of the SIP 183 (Session Progress) response. 

12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 
The SCC AS acknowledges the PRACK request. 

14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) reponse to the MSC server. 

15. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.17.2-2 

Table A.17.2-2: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sipimscl.visitl.net :1357 SIP/2.0 

Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 68 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel : +l-237-555-3333> ; tag=314159 

To: <tel:+l-237-555-llll>;tag=17182 8 

Call -ID: Cb03a0s09a2sdfglkj4 90 3 34 

Cseq: 129 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< state -info>early< /state- info> 
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<direction>receiver</direction> 
</ state- and- event -info> 



16. SIP INFO request (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in terminating alerting state. 

17. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities) 

The MSC server acknowledges the receipt of the SIP INFO request. 

18. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

19. MSC goes in Call received state 

The MSC enters Call received state due to the information received in the SIP INFO request. 
20a. User answers the call 

20. CC CONNECT message from SC UE A to MSC server 

The SC UE A accepts the call and sends CC CONNECT message. 

21. SIP INFO request (MSC server to intermediate IM CN subsystem entities) - see example in 
table A.17.2-3 

Table A.17.2-3: INFO request (MSC server to intermediate IM CN subsystem entities) 



INFO sip: sccasl .homel .net;gr SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 

Max-Forwards: 68 

Route : <sip : scscf 1 .homel .net; lr> 

From: <tel : +l-23 7-555-llll> ; tag=17182 8 

To: <tel: +l-237-555-3333>;tag=171828 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 130 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . s t ate -and- event -info+xmls 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

<event >call - accept ed< /event > 
< /state- and- event -info> 



22. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets 
informed that the SC UE A has accepted the call. 

23 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the 
call 

24 SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The SIP 200 (OK) response is forwarded to the MSC server. 

25 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call. 

26 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
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The SIP 200 (OK) response is forwarded to the far end) 

27 SIP ACK request (far end to intermediate IM CN subsystem entities) 

The far end UE acknowledges the SIP 200 (OK) response received from SCC AS 

28 SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

29 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to indicate the successful access transfer to the MSC server. 

30 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the MSC server. 

31 CC CONNECT ACKNOWLEDGE message (MSC server to SC UE A) 

32 SIP ACK request (MSC server to intermediate IM CN subsystem entities) 
MSC server acknowledges the SIP 200 (OK) response received from SCC AS 

33 SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

34-41 CANCEL Processing 

The SCC AS cancels the SIP dialog towards the SC UE 

NOTE: Steps 36-41 are performed only if the SC UE A usesGm after the PS-CS access transfer in alerting phase 
is completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalling between the SC UE A and the network 

A. 17.3 Session transfer for originating call is in alerting phase 
using PS to CS SRVCC procedure: PS to CS 

In the example flow at the figure A.17.3-1, SC UE A has invited for an originating session with speech media 
component which is anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from 
the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access. 
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Figure A.17.3-1: PS-CS SRVCC, incoming call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has setup an outgoing call 

The outgoing call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC 
UE A has received a SIP 180 (Ringing) response. 
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la. The ringing tone is played to the originating user 

The ringing tone is played by the originating UE as the locally gernerated ringing tone. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The ringing tone is kept playing to the originating user. 

3. SIP INVITE request transferring the session (MSC server to intermediate IM CN subsystem entities) - see 
example in table A.17.3-1 

The MSC server sends an initial SIP INVITE request with STN-SR. 

Table A.17.3-1 : SIP INVITE request (MSC server to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

Route : <sip:icscfl. visitl .net; lr> 

P-Asserted- Identity: <tel : +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visitl .net : 13 5 7>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

+g. 3gpp . srvcc-alerting 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv-Info : g. 3gpp . state -and- event 
Content-Type: application/sdp 
Content-Length: (...) 
P-Early-Media : supported 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 

Contact: contains the +g.3gpp.srvcc-alerting feature tag. 
4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF. 
4a. Remote Leg Update 
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The sec AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. The SCC AS performs the Remote Leg update by sending SIP UPDATE request 
towards the remote UE B. 

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request 
and the information previously stored against this session. 

6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B. 

7. SIP 200 (OK) response (UE B to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the far end sends a 
SIP 200 (OK) response. 

8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 183 (Session Progress) response containing the SDP answer as received from the far 
end UE. The SDP answer indicates that resources are available 

10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the MSC server. 

11. SIP PRACK request (MSC server to Intermediate IM CN subsystem entities) 
The MSC acknowledges the receipt of the SIP 183 (Session Progress) response. 

12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 
The SCC AS acknowledges the PRACK request. 

14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) reponse to the MSC server. 

15. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.17.3-2 

Table A.17.3-2: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip: mscl.visitl.net :1357 SIP/2.0 

Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 68 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel: +l-237-555-3333>; tag=314159 

To: <tel:+l-23 7-555-llll>;tag=17182 8 

Call -ID: Cb03a0s0 9a2sdfglkj4 90 3 34 

Cseq: 129 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . s t ate -and- event -info+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< state- info>early< /state- info> 

<direction>initiator< /direct ion> 
< /state- and- event -info> 
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16. SIP INFO request (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in originating alerting state. 

17. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities) 

The MSC Server acknowledges the receipt of the SIP INFO request. 

18. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

19. MSC goes in Call delivered state 

The MSC enters Call delivered state due to the information received in the SIP INFO request. 

20. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 
The UE B accepts the call and sends a SIP 200 (OK) response. 

21. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 
The SIP 200 (OK) response is forwarded to SCC AS. 

22 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends the SIP 200 (OK) response to indicate that the terminating UE B has accepted the call. 

23 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 
The SIP 200 (OK) response is forwarded to the MSC server. 

24 CC CONNECT message (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the far end has accepted the call. 
24a Stop the ringing tone 

The UE stops playing the locally generated ringing tone. 

25 CC CONNECTACKNOWLEDGE (MSC server to SC UE A) 
SC UE A acknowledges the CS CONNECT message. 

26 SIP ACK request (MSC server to intermediate IM CN subsystem entities) 
The MSC server acknowledges the SIP 200 (OK) response received from SCC AS 

27. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

28 SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the SIP 200 (OK) response received towards far end. 

29 SIP ACK request (Intermediate IM CN subsystem entities to far end) 
The SIP ACK request is forwarded towards the far end. 

30 - 33 The SCC AS releases the original source leg towards the SC UE A 

The SCC AS sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC 
UFA 

NOTE: Steps 31-32 are performed only if the SC UE A uses Gm the PS-CS access transfer in alerting phase is 
completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalhng between the SC UE A and the network 
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A.1 7.4 User answers in PS domain; Handover to CS successful 

In the example flow in figure A.17.4-1, SC UE A has an incoming session with speech media component which is 
anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, 
the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access. However the user answers the call 
in E-UTRAN and the SC UE sends a SIP 200 (OK) response to the SCC AS. It this scenario the handover to CS is 

successful. 
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Figure A.17.4-1 : SIP 200 OK from SC UE received by SCC AS: Handover to CS successful 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1 SC UE A has received an incoming call and is in Ringing State 
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The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and 
SC UE A has sent a 180 (Ringing) response. 

2-5 MSC server sends session transfer request. SCC AS sends SIP UPDATE to update the remote end 

These steps are identical to steps 3-6 in subclause A. 17.2. 

6 User answers the call when the UE is still in the source E-UTRAN access 

7-8 SIP 200 (OK) response (SC UE to intermediate IM CN subsystem entities to SCC AS) 

The SCC AS performs no additional actions on receipt of the SIP 200 (OK) i.e. the SCC AS does not confirm 
reception of the SIP 200 (OK) response with SIP ACK request and performs no actions on dialogs with UE B 
and with MSC server. 

9-21 Continuation of procedure for PS to CS SRVCC in Alerting Phase 

These steps are identical to steps 7-19 in subclause A. 17.2. 

22 UE receives H/O command from source E-UTRAN 

23 UE retunes to 3G 

24 CC CONNECT message from SC UE A to MSC server 

The SC UE A sends the CC CONNECT message as it did not receive a SIP ACK to the SIP 200 (OK) sent in 

step 7. 

25-37 Continuation of procedure for PS to CS SRVCC in Alerting Phase 

These steps are identical to steps 21-33 in subclause A. 17.2. 
38-39 SIP ACK request (SCC AS to intermediate IM CN subsystem entities to SC UE) 

The SCC AS confirms reception of the SIP 200 (OK) response received in message 8. 
40 Release original SIP dialog 

The SCC AS releases the SIP dialog towards the SC UE. 

NOTE: Step 39 is performed only if the SC UE A uses Gm after the PS-CS access transfer in alerting phase is 
completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalling between the SC UE A and the network 

A. 17.5 User answers in PS domain; Handover to CS not 
successful 

In the example flow in figure A. 17.5-1, SC UE A has an incoming session with speech media component which is 
anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, 
the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access. However the user answers the call 
in E-UTRAN and the SC UE sends a SIP 200 (OK) response to the SCC AS. In this scenario the handover to CS is not 
successful because the source E-UTRAN decides to terminate the handover procedure before its completion. In a 
similar scenario, the UE can also encounter a failure after it receives the handover command but does not successfully 
transition to 3GPP UTRAN/GERAN. 
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Figure A.17.5-1 : SIP 200 OK from SC UE received by SCC AS: Handover cancelled 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1 SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and 
SC UE A has sent a 180 (Ringing) response. 

2-18 Continuation of procedure for PS to CS SRVCC in Alerting Phase 

These steps are identical to steps 3-19 in subclause A. 17.2. 

19 User answers the call when the UE is still in the source E-UTRAN access 

20-21 SIP 200 (OK) response (SC UE to intermediate IM CN subsystem entities to SCC AS) 

The SCC AS performs no additional actions on receipt of the SIP 200 (OK) response i.e. the SCC AS does 
not confirm reception of the SIP 200 (OK) response with SIP ACK request and performs no actions on 
dialogs with UE B and with MSC server. 

9-21 Continuation of procedure for PS to CS SRVCC in Alerting Phase 

These steps are identical to steps 7-19 in subclause A. 17.2. 

22 SC UE A receives PS to CS SRVCC Handover Cancelled command from source E-UTRAN 

23-26 SIP UPDATE request (SC UE to intermediate IM CN subsystem entities to SCC AS to UE B) 

SC UE A sends a SIP UPDATE request with a SDP offer, including the media characteristics as used in the 
existing dialog and with a Reason header field containing protocol "SIP" and reason parameter "cause" with 
value "487" as specified in IETF RFC 3326 [57] and with reason-text set to "handover cancelled". 

NOTE 2: In the case that the handover command was received but the UE did not transition to the CS domain, the 
UE sends the SIP UPDATE request as described above, but with reason-text set to "failure to transition to 
CS domain". 

27-30 SIP 200 (OK) response to the SIP UPDATE request (UE B to SCC AS to intermediate IM CN 
subsystem entities to SC UE A) 

31-32 SIP 480 (Temporary Unavailable) response (SCC AS to intermediate IM CN subsystem entities to 
MSC server) 

The SCC AS responds to the MSC server with a SIP 480 (Temporary Unavailable) response which indicates 
that it is unable to go ahead with the session transfer. 

33-36 Continuation of procedure for PS to CS SRVCC in Alerting Phase 

These steps are identical to steps 25-28 in subclause A. 17.2. The SCC AS sends SIP 200 (OK) response to 
UE B as final confirmation to the original session and UE B sends SIP ACK request back to the SCC AS. 

37-38 SIP ACK request (SCC AS to intermediate IM CN subsystem entities to SC UE) 

The SCC AS confirms reception of the SIP 200 (OK) response received in message 21. 

A. 17.6 Session transfer for originating call is in alerting phase with 
forked responses using PS to CS SRVCC procedure: PS to 
CS 

In the example flow at the figure A. 17.6-1, SC UE A initiates an originating session with speech media component 
which has received several forked responses. The call is anchored at SCC AS and in alerting phase. Based upon 
measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC 
handover to CS access. 
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Figure A.17.6-1: PS-CS SRVCC, incoming call in alerting phase with forked responses 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-4. SIP INVITE request (SC UE A to Terminating network Intermediate IM CN subsystem entities) - see 
example in table A.17.6-1 
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SC UE A sends an outgoing call to the terminating party. The call has been anchored at the SCC AS. 
Table A.1 7.6-1 : SIP INVITE request (UE to Intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visited2 .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P- Preferred- Service : urn: urn- 7 : 3gpp- service. ims . icsi .mmtel 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec -agree 

Supported: precondition, lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 
c=B642; port-s=7531 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



5. SIP INVITE request (Terminating network Intermediate IM CN subsystem entities to UE B) 

The Terminating network Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, 
determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE B. 

6. SIP INVITE request (Terminating network Intermediate IM CN subsystem entities to UE C) 

The Terminating network Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, 
determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE C. 

7-11. SIP 180 (Ringing) response to SIP INVITE request (UE B to UE A though SCC AS) 

The remote UE B responds with SIP 180 (Ringing) response. And a dialog (dialog 1) has been established 
between UE A and UE B. 
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Table A.1 7.6-7: SIP 180 (Ringing) response (UE B to Terminating network Intermediate IM CN 

subsystem entities) 



SIP/2.0 180 Ringing 

Record- Route : <sip ipcscf 1 . visitedl .net; lr> 
Via: 

Max- Forwards : 6 

P-Asserted- Identity: <tel:+l-212-555-2222> 
Privacy: 
From: 

To: <tel:+l-212-555-2222>; tag=aaa 
Call-ID: 
Cseq: 
Require : 
Supported: 

Contact : <sip :user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d^9- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: 

Content-Type : 
Content-Length : 

v=0 

0=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 

s = - 

C=IN IP6 1234 : :55 :66 :77:88 

t = 

m=audio 4456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



12-16. SIP 180 (Ringing) response to SIP INVITE request (UE C to UE A though SCC AS) 

The remote UE C responds with SIP 180 (Ringing) response. And a dialog (dialog 2) has been established 
between UE A and UE B. 
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Table A.17.6-12: SIP 180 (Ringing) response (UE B to Terminating network Intermediate IM CN 

subsystem entities) 



SIP/2.0 180 Ringing 

Record- Route : <sip ipcscf 1 . visitedl .net; lr> 
Via: 

Max- Forwards : 6 

P-Asserted- Identity: <tel:+l-212-555-2222> 
Privacy: 
From: 

To: <tel:+l-212-555-2222>; tag=bbb 
Call-ID: 
Cseq: 
Require : 
Supported: 

Contact : <sip :user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d^9- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: 

Content-Type : 
Content-Length : 

v=0 

0=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 

s = - 

C=IN IP6 1234 : :55 :66 :77:88 

t = 

m=audio 4456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



17. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

18. SIP INVITE request transferring the session (MSC server to originating network intermediate IM CN 
subsystem entities) - see example in table A.17.6-18 

The MSC server sends an initial SIP INVITE request with STN-SR 
Table A.17.6-18: SIP INVITE request (IVISC server to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

Route : <sip:icscfl.visitl .net; lr> 

P- Asserted- Identity: <tel : +1-237- 555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call-ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl . visitl .net : 1357>; +g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Recv-Info : g. 3gpp . state -and- event 

Content-Type: application/sdp 

Content-Length: (...) 

P-Early-Media : supported 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
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t=o 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 

19. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF. 

20. Remote Leg Update 

The SCC AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. Since the existing session has forked responses, more than one dialog can be 
correlated to the SIP INVITE due to STN-SR The SCC AS performs the Remote Leg update towards all the 
correlated dialogs. 

21-23. SIP UPDATE request (SCC AS to UE B through Intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request towards dialog 1 to remote UE B based upon 
the received SIP INVITE request in step 19. 

24-26. SIP 200 (OK) response (Remote UE B to SCC AS through Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE B 
sends 200 OK. 

27-28. SIP 183 (Session Progress) response (SCC AS to MSC server through Intermediate IM CN subsystem 
entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the remote UE B to the 
MSC server. The SDP answer indicates that resources are available 

29-30. SIP PRACK request (MSC server to SCC AS through Intermediate IM CN subsystem entities) 

The MSC acknowledges the receipt of the 183 Session Progress by sending SIP PRACK request to the SCC AS. 
31-32. SIP 200 (OK) response (SCC AS to MSC server through Intermediate IM CN subsystem entities) 

The SCC AS acknowledges the PRACK with the SIP 200 (OK) reponse to the MSC server. 

33. SIP INFO request (SCC AS to Originating network intermediate IM CN subsystem entities) - see example 
in table A.17.6-33 

Table A.17.6-33: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip: mscl.visitl.net :1357 SIP/2.0 

Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 68 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel: +l-237-555-3333>; tag=314159 

To: <tel:+l-23 7-555-llll>;tag=17182 8 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 129 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 
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Content-Length : 

<?xml version="l . 0" encoding="UTF-8" 

< state- and- event -info> 

< state- info>early< /state- info> 
<direction>initiator< /direct ion> 

< /state- and- event -info> 



34. SIP INFO request (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in originating alerting state. 

35. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities) 

The MSC Server acknowledges the receipt of the SIP INFO request. 

36. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the SCC AS. 

37-39. SIP UPDATE request (SCC AS to UE C through Intermediate IM CN subsystem entities) 

In parallel with step 21, the SCC AS acting as a B2BUA generates a SIP UPDATE request towards dialog 2 to 
remote UE C based upon the received SIP INVITE request in step 19. 

40-42. SIP 200 (OK) response (Remote UE C to SCC AS through Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE C 
sends 200 OK. 

43-44. SIP 183 (Session Progress) response (SCC AS to MSC server through Intermediate IM CN subsystem 
entities) 

The SCC AS sends a SIP 183 (Session Progress) containing the SDP answer as received from the remote UE C 
to the MSC server. The SDP answer indicates that resources are available 

45-46. SIP PRACK request (MSC server to SCC AS through Intermediate IM CN subsystem entities) 

The MSC acknowledges the receipt of the 183 Session Progress by sending SIP PRACK request to the SCC AS. 
47-48. SIP 200 (OK) response (SCC AS to MSC server through Intermediate IM CN subsystem entities) 

The SCC AS acknowledges the PRACK with the SIP 200 (OK) reponse to the MSC server. 
49. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

In this example, the remote UE B accepts the call first and sends 200 (OK) response. 
50-51. 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The 200 (OK) response is forwarded to SCC AS. 
52-53 200 (OK) response (SCC AS to MSC server through Intermediate IM CN subsystem entities) 

The 200 (OK) response is forwarded to the MSC server based on the route established during step 24-28. 

54 CC CONNECT message (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the remote UE B has accepted the call. 

55 CC CONNECT ACKNOWLEDGE message (MSC server to SC UE A) 
SC UE A acknowledges the CC CONNECT message. 

56-60. SIP ACK request (MSC server to remote UE B through intermediate IM CN subsystem entities) 
The MSC server acknowledges the SIP 200 (OK) response by sending The SIP ACK request to remote UE B. 
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61 SIP CANCEL request (Terminating network intermediate EM CN subsystem entities to remote UE C) 

The intermediate IM CN subsystem entities send the SIP CANCEL request to remote UE C to release the call 
towards remote UE C. 

62 SIP 200 (OK) response to SIP CANCEL request (UE-3 to Intermediate IM CN subsystem entities) 

Remote UE C responds SIP 200 (OK) response to the SIP CANCEL request. 

63-66 The SCC AS releases the original source leg towards the SC UE A 

The SCC AS sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC 
UEA 

NOTE: Steps 64-65 are performed only if the SC UE A Gm after the PS-CS access transfer in alerting phase is 
completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalling between the SC UE A and the network 

A. 17.7 Session transfer for originating call is in alerting phase 
using SRVCC procedure with ATCF: PS to CS 

In the example flow at the figure A. 17.7-1, SC UE A has invited for an originating session with a CAT media 
component which is anchored at ATGW. The session is in alerting phase. Based upon measurement reports sent from 
the UE to E-UTRAN, the source E-UTRAN decides to trigger a SRVCC handover to CS access. 
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Figure A.1 7.7-1 : PS-CS SRVCC, outgoing call in alerting phase with CAT media anchored at ATGW 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has setup an outgoing call 

The outgoing call with the CAT media has been anchored at the ATGW. Both ends have reserved the resources 
and SC UE A has received a SIP 180 (Ringing) response. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.17.7-3 
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Table A.17.7-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel : +1-237- 555 -2222 > 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

P-Early-Media : supported 

From: <tel:+l-237-555-llll>;tag=17182 8 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4903 34 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 :3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 1357>;+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4, SIP INVITE request (ATCF to SCC AS)-see example in table A.17.7-4 

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a 
new SIP INVITE request to the SCC AS using the stored ATU-STI for PS to CS SRVCC. The ATCF updates 
the SCC AS via the new dialog indicating that the transfer has taken place. As there is no update in the SDP 
information, no remote end update will be performed. 

Table A.17.7-4: SIP INVITE request (ATCF to SCC AS) 



INVITE sip: AUT-STI10sccas.homel.net SIP/2.0 

Via: SIP/2. 0/UDP actf .visited2 .net :5060;branch=z9hG4bk731b87 

Max-Forwards: 70 

P- Asserted- Identity: <tel:+l-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

P-Early-Media: supported 

From: <tel: +1-23 7- 555-3333 >;tag=1888828 

To: <tel:+l-237-555-4444> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90444 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Require: tdialog. 

Record- Route : <sip : actf . visited2 .net : 5 06 ; lr> 

Target-Dialog: me03a0s09a2sdf gjkl491777 ; remote-tag=774321 ; local-tag=64727891 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 5 7 >; +g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 
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Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ggg 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ggg 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: contains the ATU-STI for PS to CS SRVCC, that resolves (e.g. via DNS access) to the IP 
address of the I-CSCF. 

Target-Dialog: specifies that the existing dialog is related with this request. 

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request 
from the sec AS. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

SDP: the media information at ATGW. 

5-6. SIP 183 (Session Progress) response (SCC AS to MSC Server) 

The session achored is in alerting state, the SCC AS sends the SIP 183Session Progress response to the MSC 
server. 

7-8. SIP PRACK reqeust (MSC Server to SCC AS) 

9-10. SIP 200 (OK) response (SCC AS to MSC Server) 

11. The CAT media is tranfered to the CS access, and kept playing to the originating user. 

9. SIP 183 (Session Progress) response (SCC AS to ATCF) 

10. SIP PRACK request (ATCF to SCC AS) 

11. SIP 200 (OK) response (SCC AS to ATCF) 

12-13. SIP INFO request (SCC AS to MSC Server) - see example in table A.17.7-12 

Table A.17.7-12: INFO request (SCC AS to MSC Server) 



INFO sip: mscl.visitl.net : 1357 SIP/2.0 

Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23 .1 

Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel:+l-237-555-3333>;tag=31415 9 

To: <tel: +1-237- 555 -llll>;tag=171828 

Call -ID: Cb03a0s0 9a2sdfglkj 490334 

Cseq: 129 INFO 

Info -Package : g. 3gpp . state -and- event -info 

Content-Type: application/ vnd. 3gpp . state-and-event-info+xmls 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< state- info>early< /state- info> 

<direction>initiator</direction> 
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< /state -and- event -info> 



14-15. SIP 200 (OK) response (MSC server to SCC AS) 

The MSC Server acknowledges the receipt of the SIP INFO request. 

16. MSC goes in Call delivered state 

The MSC enters Call delivered state due to the information received in the SIP INFO request. 

17. The User B answers the call 

18. SIP 200 (OK) response (UE B to CAT AS B) 

The UE B accepts the call and sends a SIP 200 (OK) response. 

19. The CAT AS stops the CAT media upon receving the SIP 200 OK response. 
20-22. SIP 200 (OK) response (CAT AS to MSC Server) 

The SIP 200 (OK) response is forwarded to MSC Server. 

23. CC CONNECT message (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the far end has accepted the call. 

24. CC CONNECTACKNOWLEDGE (SC UE A to MSC server) 
SC UE A acknowledges the CS CONNECT message. 

25-28. SIP ACK request (MSC server to UE B) 

The MSC server acknowledges the SIP 200 (OK) response. 

29-32. The SCC AS releases the original source leg towards the SC UE A 

The SCC AS sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC 
UFA 

NOTE: Steps 29-32 are performed only if the SC UE A uses Gm the PS-CS access transfer in alerting phase is 
completed; otherwise, the SC UE A and the network release the source access leg locally, without any 
signalling between the SC UE A and the network. 

A.1 7.8 Session transfer for terminating call is in alerting phase 
using SRVCC procedure with ATCF: PS to CS 

In the example flow at the figure A. 17.8-1, SC UE B has an incoming session with speech media component which is 
anchored at ATCF. The session is in alerting phase, and the CAT media is played to the originating UE A. Based upon 
measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC 
handover to CS access. 
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Figure A.17.8-1 : PS-CS SRVCC, incoming call in alerting phase with CAT media 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE B has received an incoming call and is in Ringing State 
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The incoming call has been anchored at the ATCF of SC UE B. Both ends have reserved the resources and SC 
UE A has sent a 180 (Ringing) response. 

2. SC UE B attaches to the CS domain 

UE B sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.17.8-3 

Table A.17.8-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel : +1-237- 555 -2222 > 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

P-Early-Media : supported 

From: <tel : +l-237-555-llll> ; tag=17182 8 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 57>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4. SIP INVITE request (ATCF to SCC AS)-see example in table A.17.8-4 

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a 
new SIP INVITE request to the SCC AS using the stored ATU-STI for PS to CS SRVCC. The ATCF updates 
the SCC AS via the new dialog indicating that the transfer has taken place. As there is no update in the SDP 
information, no remote end update will be performed. 

Table A.17.8-4: SIP INVITE request (ATCF to SCC AS) 



INVITE sip:AUT-STIl@sccas. homel.net SIP/2.0 

Via: SIP/2. 0/UDP actf .visited2 . net : 5060 ;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel:+l-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 
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P-Early-Media : supported 

From: <tel: +1-237- 555- 3333 >;tag=1888828 

To: <tel:+l-237-555-4444> 

Call -ID: Cb03a0s09a2sdfglkj 490444 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Require: tdialog, 

Record- Route : <sip : actf . visited2 .net : 5060 ; lr> 

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 57>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ggg 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ggg 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the ATU-STI for PS to CS SRVCC, that resolves (e.g. via DNS access) to the IP 
address of the I-CSCF. 

Target-Dialog: specifies that the existing dialog is related with this request. 

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request 
from the sec AS. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

SDP: the media information at ATGW. 

5-6. SIP 183 (Session Progress) response (SCC AS to MSC server) 

The session achored is in alerting state, the SCC AS sends the SIP 183Session Progress response to the MSC 
server. 

7-8. SIP PRACK reqeust (MSC Server to SCC AS) 

9-10. SIP 200 (OK) response (ATCF to MSC Server) 

11-12. SIP INFO request (SCC AS to MSC Server) - see example in table A.17.8-11 

Table A.17.8-11 : INFO request (SCC AS to MSC Server) 



INFO sip:mscl.visitl.net:1357 SIP/2.0 






Via SIP/2. 0/UDP sip: sccasl .homel .net;branch= 


29hG4bK332b23.1 


Max- Forwards : 68 






Route : <sip : scscf 1 .homel .net; lr> 






From: <tel:+l-237-555-3333>;tag=31415 9 






To: <tel: +1-237- 555- llll>;tag=171828 






Call -ID: Cb0 3a0s09a2sdfglkj4 90 3 34 






Cseq: 129 INFO 






Info-Package : g. 3gpp . state-and-event-info 






Content-Type : application/vnd. 3gpp . state-and 


- event - 


info+xmls 


Content-Length: 
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<?xml version="l . 0" encoding="UTF-8" ?> 

< state- and- event -info> 

< state- info>early< /state- info> 
<direction>receiver< /direct ion> 

< /state- and- event -info> 



13-14. SIP 200 (OK) response (MSC server to ATCF) 

The MSC server acknowledges the receipt of the SIP INFO request. 

15. MSC goes in Call received state 

The MSC enters Call received state due to the information received in the SIP INFO request. 

16. The User B answers the call 

17. CC CONNECT message from SC UE B to MSC server 

The SC UE B accepts the call and sends CC CONNECT message. 
18-19. SIP INFO request (MSC server to SCC AS) - see example in table A.17.8-18 
Table A.17.8-18: INFO request (MSC server to SCC AS) 



INFO sip: sccasl .homel .net;gr SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ;branch=z9hG4bk731b87 

Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel: +1-237- 555- 3333 >;tag=171828 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 130 INFO 

Info -Package : g. 3gpp . state -and- event -info 

Content -Type : application/vnd. 3gpp . s t ate -and- event -info+xmls 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< event >call- accept ed< /event > 
< /state -and- event -info> 



20-21. SIP 200 (OK) response (SCC AS to MSC Server) 

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE B has accepted the 
call. 

22. SIP 200 (OK) response (SCC AS to CAT AS) 

The SIP 200 (OK) response is forwarded to the CAT AS by SCC AS. 

23. The CAT AS stops the CAT media upon receving the SIP 200 OK response. 

24. SIP 200 (OK) response (CAT AS to UE A) 

The SIP 200 (OK) response is forwarded to UE A. 
25-26 SIP ACK request (far end UE A to SCC AS) 

The far end UE acknowledges the SIP 200 (OK) response received from SCC AS 
27-28 SIP 200 (OK) response (SCC AS to MSC Server) 

The SCC AS sends a SIP 200 (OK) response to indicate the successful access transfer to the MSC server. 
29. CC CONNECT ACKNOWLEDGE message (MSC server to SC UE B) 
30-31. SIP ACK request (MSC server to SCC AS) 
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MSC server acknowledges the SIP 200 (OK) response received from SCC AS. 
32-39. CANCEL Processing 

The SCC AS cancels the SIP dialog towards the SC UE 

NOTE: Steps 32-39 are performed only if the SC UE B uses Gm after the PS-CS access transfer in alerting phase 
is completed; otherwise, the SC UE B and the network release the source access leg locally, without any 
signalling between the SC UE B and the network. 

A.1 8 Signalling flows for PS to CS Access Transfer: PS to 
CS SRVCC enhancements using ATCF 

A.1 8.1 Introduction 

The signalling flows in the subclause demonstrate the PS to CS SRVCC enhancements using ATCF. The following 
signalling flows are included: 

subclause A. 18.2 shows an example of PS to CS SRVCC enhancements using ATCF and without media 
anchored. 

subclause A. 18. 3 shows an example of PS to CS SRVCC enhancements using ATCF and media anchored. 

A.1 8.2 Signalling flows for PS to CS Access Transfer: PS to CS 
SRVCC enhancements using ATCF and without media 
anchored 

The signalling flow shown in figure A. 18.2-1 gives an example for PS to CS access transfer when using ATCF 
enhancements and without media anchored. In this case, the ATCF has been included in the path for subsequent 
transactions created at registration, but media has not been anchored in ATGW. 
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Figure A.I 8.2-1 Signalling flows for PS to CS access transfer: PS to CS SRVCC enhancements using 

ATCF and without media anchored 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active session with UE B 

There is an ongoing PS bearer between the UE A and the remote end UE B. The media is not anchored at 
ATGW. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPPTS 23.216 [49]. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.2-3 

Table A.18.2-3: SIP INVITE request (IVISC server to ATCF) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P- Asserted- Identity: <tel:+l-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555- llll>;tag=171828 

To: <tel: +l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 
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Contact : <sip : mscl .visit 1 .net : 13 5 7 >; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933S15 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4-5. SIP INVITE request (ATCF to SCC AS via I-CSCF)- see example in table A.18.2-4 

Since the media has not been anchored at the ATGW, the ATCF forwards the SIP INVITE request to the SCC 
AS by replacing the request URI to the stored ATU-STI for PS to CS SRVCC. 

Table A.18.2-4: SIP INVITE request (ATCF to I-CSCF) 



INVITE sip:AUT-STIl@sccas.homel .net SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel:+l-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555- llll>;tag=171828 

To: <tel: +l-237-555-4444> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 57>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



6-7. SIP re-INVITE request (SCC AS to UE B via S-CSCF) 
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The sec AS based on the content of the C-MSISDN correlates the SIP INVITE request to the local and remote 
call legs of the existing session between the UE A and the remote end. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

8-9. SIP 200 (OK) response (UE B to SCC AS via S-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

10-11. SIP ACK request (SCC AS to UE B via S-CSCF) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

12-13. SIP 200 (OK) response (SCC AS to ATCF via I-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the ATCF. 

14. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC server. 

15. SIP ACK request (MSC server to ATCF) 

The MSC server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the ATCF. 
16-17. SIP ACK request (ATCF to SCC AS via I-CSCF) 

The ATCF generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

18-21. SIP BYE request (SCC AS to UE via I-CSCF, ATCF and P-CSCF) 

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request 
to the UE A. 

22-24. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF) 

Upon receiving the SIP BYE request over the old IP -CAN, the UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A reUnquishes all resources pertaining to the old IP-CAN. 

NOTE: Steps 21-22 are performed only if the UE A uses Gm after the PS-CS access transfer is completed; 

otherwise, the UE A and the network release the source access leg locally, without any signalling between 
the UE A and the network 

A.18.3 Signalling flows for PS to CS Access Transfer: PS to CS 
SRVCC enhancements using ATCF and media anchored 

The signalling flow shown in figure A. 18.3-1 gives an example for PS to CS access transfer for PS to CS SRVCC 
enhancements using ATCF and media anchored. In this case, the media is anchored in ATGW and ATCF has been 
included in the path for subsequent transactions created at registration. 
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Figure A.I 8.3-1 Signalling flows for PS to CS access transfer: PS to CS SRVCC enhancements using 

ATCF and media anchored 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active session with UE B 

There is an ongoing IP bearer between the UE A and the remote end UE B. The media is anchored at ATGW. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPPTS 23.216 [49]. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.3-3 

Table A.18.3-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel: -1-1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel:-fl-237-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm-i-6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel:-fl-237-555-llll>;tag=171828 

To: <tel: -fl-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 57>; -fg. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
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c=IN IP6 5555 : : aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4. Configure ATGW (ATCF to ATGW) 

Upon receiving the access transfer message, the ATCF correlates the transferred session using C-MSISDN. The 
ATCF updates the ATGW by replacing the existing PS access leg media path information with the new CS 
access leg media path information, by sending a Configure ATGW message to ATGW. 

5. Configure ATGW ACK (ATGW to ATCF) 

The ATGW sends Configure ATGW Acknowledgment message back to ATCF. 

6. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF sends the SIP 200 OK response to the MSC server with the media information allocated by the 
ATGW during session establish procedure. In the SIP 200 OK response, the ATCF includes the Record-Route 
header field containing its SIP URI that indicate where the ATCF expect to receive the indialog request sent by 
the MSC. In the Contact header field, the ATCF inserts the saved URI of the UE B that the UE A received from 
the UE B when the IP bearer between the UE A and the UE B was established. 

7. SIP ACK request (MSC server to ATCF) 

8. SIP INVITE request (ATCF to I-CSCFs)-see example in table A.18.3-8 

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a 
new SIP INVITE request to the SCC AS using the stored ATU-STI for PS to CS SRVCC. When resolving the 
ATU-STI for PS to CS SRVCC (e.g. via DNS access), the ATCF obtains the IP address of the I-CSCF. The 
ATCF updates the SCC AS via the new dialog indicating that the transfer has taken place. As there is no update 
in the SDP information, no remote end update will be performed. 

Table A.18.3-8: SIP INVITE request (ATCF to I-CSCF) 



INVITE sip :AUT-STIl@sccas .homel.net SIP/2.0 

Via: SIP/2. 0/UDP atcf .visited2 .net :5060;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel : +l-23 7-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel : +1-237- 555 -3333 >; tag=1888828 

To: <tel: +l-237-555-4444> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90444 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Require: tdialog, 

Record- Route : <sip : atcf . visited2 .net:5060;lr> 

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service. ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 1357>;+g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
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Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ggg 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ggg 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the ATU-STI for PS to CS SRVCC, that resolves (e.g. via DNS access) to the IP 
address of the I-CSCF. 

Target-Dialog: specifies that the existing dialog is related with this request. 

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request 
from the sec AS. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

SDP: the media information at ATGW. 

9. SIP INVITE request (I-CSCF to SCC AS) 

The I-CSCF forwards the SIP INVITE request to the SCC AS. 

10. SIP 200 (OK) response (SCC AS to I-CSCF) 

Since there is no update in the session description, no remote end update will be performed. The SCC AS sends 
confirmation response to the ATCF which contain the SDP answer that the SCC AS stored during the original 
session establishment procedure. The SIP 200 (OK) response also includes the Record-Route header field(s) that 
was constructed by the SCC AS adding its SIP URI to the Record-Route header field(s) that was received in the 
initial SIP INVITE request in step 9. The SIP URI of the SCC AS specifies where the SCC AS expects to receive 
the in-dialog request from the ATCF. 

11. SIP 200 (OK) response (I-CSCF to ATCF) 

12-13. SIP ACK request (ATCF to SCC AS via I-CSCF) 

14-17. SIP BYE request (SCC AS to UE A via I-CSCF, ATCF and P-CSCF) 

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request 
to the UE A. 

18-21. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF) 

Upon receiving the SIP BYE request, the UE A sends a SIP 200 (OK) response to the SCC AS. Subsequently, 
the UE A relinquishes all resources pertaining to the old IP -CAN. 

NOTE: Steps 17-18 are performed only if UE A uses Gm after the PS-CS access transfer is completed; otherwise, 
the UE A and the network release the source access leg locally, without any signalling between the UE A 
and the network 
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A. 18.4 Session transfer for originating call is in alerting phase 
using PS to CS SRVCC procedure with ATCF: PS to CS 

In the example flow at the figure A. 18.-1, SC UE A has invited for an originating session with speech media component 
which is anchored at ATCF. The session is in alerting phase. Based upon measurement reports sent from the UE to E- 
UTRAN, the source E-UTRAN decides to trigger a SRVCC handover to CS access. 
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NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

Figure A.18.4-1: PS-CS SRVCC, incoming call in alerting phase 
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1. SC UE A has setup an outgoing call 

The media of the outgoing call has been anchored at the ATGW. Both ends have reserved the resources and SC 
UE A has received a SIP 180 (Ringing) response. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS 
SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

3. SIP INVITE request (MSC server to ATCF) - see example in table A.18.4-3 

The MSC server sends an initial SIP INVITE request transferring the session with the recived STN-SR. 

Table A.18.4-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel : +1-237- 555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service. ims .icsi .mmtel 

Contact : <sip : mscl .visitl .net : 13 5 7>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" ; 

g . 3gpp . srvcc-alerting 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv-Info : g. 3gpp . state -and- event 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 

4. SIP INVITE request (ATCF to intermediate IM CN subsystem entities) - see example in table A.18.4-4 

The ATCF sends the initial SIP INVITE request replacing the STN-SR with an ATU-STI for PS to CS SRVCC 
associated with a session in the transferable session set to the intermediate IM CN subsystem entities. 

Table A.18.4-4: SIP INVITE request (ATCF to intermediate IM CN subsystem entities) 



INVITE sip: sccasl-atu-sti .homel .net SIP/2.0 

Via: SIP/2. 0/UDP atcf .visitedl.net :5060;branch=z9hG4bKnas56565, SIP/2. 0/UDP 

mscl .visitl .net ;branch=z9hG4bk731b87 

Max-Forwards: 69 

Route : <sip:icscfl.visitl.net;lr> 

P- Asserted- Identity: <tel : +1-237- 555- 1111> 
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P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel:+l-23 7-555-llll>;tag=171828 

To: <tel:+l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 57>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims .icsi .mmtel" 

g . 3gpp . srvcc-alerting 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv-Info : g. 3gpp . state -and- event 
Record- Route : <atcf . visitedl .net; lr> 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: contains the ATU-STI for PS to CS SRVCC. 

Record-Route: contains ATCF URL 

SDP: The SDP contains set of codecs supported by the MGW. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF. 

5a. Remote Leg Update 

The SCC AS correlates the initial SIP INVITE request to the local and remote call legs of the existing session 
between the UE A and the remote end. The SCC AS performs the Remote Leg update by sending SIP UPDATE 
request towards the Remote Leg. 

6. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received initial SIP INVITE 
request and the information previously stored against this session. 

7. SIP UPDATE request (Intermediate IM CN subsystem entities to remote UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B. 

8. SIP 200 (OK) response (Remote UE B to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE B 
sends a SIP 200 (OK) response. 

9. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

10. SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities) 
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The sec AS sends a 183 (Session Progress) containing the SDP answer as received from the remote UE B. The 
SDP answer indicates that resources are available 

11. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to ATCF) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the ATCF. 

12. SIP 183 (Session Progress) response (ATCF to MSC server) 

The ATCF forwards the 183 (Session Progress) response to the MSC server. 

13. SIP PRACK request (MSC server to ATCF) 

The MSC acknowledges the receipt of the 183 (Session Progress) response. 

14. SIP PRACK request (ATCF to intermediate IM CN subsystem) 

The ATCF forwards the SIP PRACK request to intermediate IM CN subsystem entities. 

15. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS. 

16. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 
The SCC AS acknowledges the PRACK request. 

17. SIP 200 (OK) response (Intermediate IM CN subsystem entities to ATCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) reponse to the ATCF. 

18. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF forwards the SIP 200 (OK) reponse to the MSC server. 

19. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.18.4-19 

The SCC AS sends a SIP INFO request that indicates that the call is an early dialog and that the SC UE was the 
initiator. 

Table A.18.4-19: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip: mscl.visitl.net :1357 SIP/2.0 

Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 70 

Route: <sip : scscf 1 .homel .net ; lr> <atcf . visitedl .net ; lr> 

From: <tel : +l-237-555-3333> ; tag=314159 

To: <tel: +1-237- 555- llll>;tag=171828 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 129 INFO 

Info-Package : g . 3gpp . state-and-event 

Content-Disposition : Info-Package 

Content -Type : application/vnd. 3gpp . state -and- event -info+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
< state- and- event -info> 

< state- info>early< /state- info> 

<direction>initiator< /direct ion> 
< /state- and- event -info> 



20. SIP INFO request (Intermediate IM CN subsystem entities to ATCF) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF. 

21. SIP INFO request (ATCF to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF. The MSC server is now 
aware that the call that is transferred is in originating alerting state. 
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22. SIP 200 (OK) response (MSC server to ATCF) 

The ATCF forwards the SIP 200 (OK) response to intermediate IM CN subsystem entities. 

23. SIP 200 (OK) response (ATCF to intermediate IM CN subsystem entities) 

The ATCF forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities. 

24. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

25. MSC goes in Call delivered state 

The MSC enters Call deUvered (N4) state as defined in 3GPP TS 24.008 [8] due to the information received in 
the SIP INFO request. 

26. SIP 200 (OK) response (Remote UE B to intermediate IM CN subsystem entities) 

The remote UE B accepts the call and sends a SIP 200 (OK) response. 

27. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to SCC AS. 

28. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends the SIP 200 (OK) response to indicate that the remote UE B has accepted the call. 

29. SIP 200 (OK) response (Intermediate IM CN subsystem entities to ATCF) 
The SIP 200 (OK) response is forwarded to the ATCF. 

30. SIP 200 (OK) response (ATCF to MSC server) 
The SIP 200 (OK) response is forwarded to the ATCF. 

31. CC CONNECT (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the remote UE B has accepted the call in accordance with 
3GPPTS 24.008 [8]. 

32. CC CONNECT ACK (MSC server to SC UE A) 

SC UE A acknowledges the CC CONNECT in accordance with 3GPP TS 24.008 [8]. 

33. SIP ACK request (MSC server to ATCF) 

The MSC server acknowledges the SIP 200 (OK) response received from SCC AS 

34. SIP ACK request (ATCF to intermediate IM CN subsystem entities) 

ATCF forwards the SIP ACK request to the intermediate IM CN subsystem entities. 

35. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. The SCC AS starts a 
operator specific timer supervising the release of the original source leg. 

36. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the SIP 200 (OK) response received towards the remote UE B. 

37. SIP ACK request (Intermediate IM CN subsystem entities to remote UE B) 
The SIP ACK request is forwarded towards the remote UE B. 

38. SIP 404 (Not Found) response (SCC AS to intermediate IM CN subsystem entities) 
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The sec AS releases the original source leg towards the SC UE A after the operator specific timer has expired 
by means of a SIP 404 (Not Found) response. 

39. SIP ACK (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is sent to SCC AS. 

40. SIP 404 (Not Found) response (Intermediate IM CN subsystem entities to ATCF) 

Intermediate IM CN subsystem entities send a SIP 404 (Not Found) response in order to release to original 
source dialog towards the SC UE A. 

41. SIP ACK (ATCF to intermediate IM CN subsystem entities) 

The SIP ACK request is sent to the intermediate IM CN subsystem entities. 

42-43.Media recources reserved in ATGW is released by ATCF. 

The ATCF orders the ATGW to release all media terminations (including termination created due to forking on 
remote end) of the used for media anchoring during call setup in. The ATGW acknowledges the release. 

44-47.SIP 404 (Not Found) response (ATCF towards SC UE A) 

The ATCF sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE 
A via P-CSCF. 

NOTE : The SC UE A can only receive the SIP 404 (Not Found) response and send the SIP ACK request if the 
signalling bearer is not suspended. 
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A.18.5 Signalling flows for PS to CS Access Transfer: SRVCC 

enhancements using ATCF with IVISC server assisted mid- 
call feature and ATCF anchored 
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2~21. PS to CS access transfer between UE A and UE B , as specified in A.18.3: SRVCC enhancements using 

ATCF and media anchored 
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Figure A.I 8.5-1 Signalling flows for PS to CS Access Transfer: SRVCC enhancements using ATCF 
with MSC server assisted mid-call feature and ATCF anchored 

1. UE A is on an active session X with UE B and a held session Y with UE C 

UE A is on an active session X with UE B and on another held session Y with UE C. Both Sessions through PS 
network are anchored at ATCF, and medias are anchored at ATGW. 

2-21. PS to CS access transfer between UE A and UE B 
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The PS to CS access transfer between UE A and UE B is specified in subclause A. 18.3: SRVCC enhancements 
using ATCF and media anchored. 

22. SIP REFER request (SCC AS to I/S-CSCF) - see example in table A.18.5-22 

The SCC AS sends a SIP REFER request to the I/S-CSCF inside the dialog created by the message 10. 

Table A.18.5-22: SIP REFER request (SCC AS to I/S-CSCF) 



REFER sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 SIP/2 . 

Via: SIP/2. 0/UDP sip : sccasl .homel .net ;branch=z9hG4bk731b8a 

Max-Forwards: 70 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

To: <tel:+l-237-555-llll>;tag=17182 8 

From: <tel : +1-237- 555- 3333 >; tag=sdfsdf 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl .homel .net 

Refer- To : <sip : additional . session.xf er .pscssrvcc@sccas .homel .net?Target- 
Dialog=ksdjfhwrklf %3Bremote-tag=S7S7235S5%3Blocal-tag=45418454&;Require = tdialog&;From=tel : +1-23 7- 
555-llll&;To = tel : +l-987-654-3210&;Content-Type = application%2Fsdp&;body=v%3D0%0D%0Ao%3D- 
%202987933S23%202987933623%20IN%2 0IP6%205555: : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%20IP6%205555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 0%2 0RTP%2FAVP%20 98%0D 
%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25 . 4%0D%0Aa%3Drtpmap : 97%20AMR%0D%0Aa%3Dfmt 
p: 97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime :20%0D%0A> 

Content-Type: multipart/mixed 

--boundaryl 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mid-call/> 

--boundaryl 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 
<srvcc-ext> 
<PS-reg-info> 

< ATCF -Management -URI> sip: at cf .visited2 . net < /ATCF -Management -URI> 
<C-MSISDN>tel:+l-237-555-llll</C-MSISDN> 
</PS-reg-inf o> 
</srvcc-ext> 
- -boundaryl- - 



Refer-To: contains the additional transferred session SCC AS URI for PS to CS SRVCC and the following 

URI header fields: 

Target-Dialog: the dialog identifier of the source access leg. 

Require: containing "tdialog" option tag 

From: contains the public user identity of the UE A 

To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 



application/vnd.3gpp.mid-call-Hxml MIME body: indicates that REFER is related to MSC server assisted mid-call 
feature. 

application/vnd.3gpp.srvcc-extH-xml MIME body: provides ATCF management URI and C-MSISDN. 
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23. SIP REFER request (I/S-CSCF to ATCF) 

The I/S-CSCF forwards the SIP REFER request to the ATCF. 

24. SIP REFER request (ATCF to MSC server) - see example in table A.18.5-24 

The ATCF forwards the REFER within the dialog. 

Table A.18.5-24: SIP REFER request (ATCF to MSC server) 



REFER sip:userl jubliclohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 SIP/2 . 

Via: SIP/2. 0/UDP sip: sccasl .homel .net;branch=z9hG4bk731b8a 

Via: SIP/2. 0/UDP sip: scscfl .homel .net, •branch=z9hG4bk869dlle 

Via: SIP/2. 0/UDP sip :atcfl. homel. net ;branch=z9hG4bk9251re3 

Max-Forwards: 70 

P-Charging-Vector : 

To: 

From: 

Call-ID: 

Cseq: 

Content-Length : 

Route : <sip :mscserverl .homel .net; lr> 

Refer-Sub: 

Supported: 

Contact : 

Refer- To : <sip : additional . session.xf erOsccas .homel .net?Target-Dialog=ksdj fhwrklf %3Bremote- 
tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +1-987-654- 
3210&;Content-Type=application%2Fsdp&;body=v%3D0%0D%0Ao%3D- 

%2 02 987933623%2 02 987933623%2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IP6%205555 : :ggg:fff :aaa:bbb%0D%0At%3D0%200%0D%0Am%3Dvideo%2 0%2 0RTP%2FAVP%2 098%0D 
%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25 . 4%0D%0Aa%3Drtpmap : 97%20AMR%0D%0Aa%3Dfmt 
p: 97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A> 

Content-Type: multipart/mixed 

--boundaryl 

Content -Type : application/vnd. 3gpp .mid-call+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mid-call/> 

--boundaryl 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 
<srvcc-ext> 
<PS-reg-info> 

<ATCF-Management-URI>sip:atcf2 .visited2 . net < /ATCF -Management -URI> 
<C-MSISDN>tel:+l-23 7-555-llll</C-MSISDN> 
</PS-reg-info> 
</srvcc-ext> 
- -boundaryl- - 



25-27. SIP 202 Accepted response 

Upon receiving the SIP REFER request, the MSC Server sends a SIP 202 (Accepted) response to ATCF, ATCF 
forwards it to the SCC AS. 

28. SIP INVITE request (MSC Server to ATCF) -see example in table A.18.5-28 

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request to the ATCF according to 
the Refer-To header field in the REFER request. MSC server also includes Route header field with the ATCF 
management URI received in the application/vnd. 3gpp.srvcc-extH-xml MIME body of the REFER request. 

Table A.18.5-28: SIP INVITE request (MSC Server to ATCF) 



INVITE sip : additional . session.xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP mscl .homel .net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

P- Asserted- Identity: <tel : +l-23 7-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-237- 555 -llll>;tag=171828 



£75/ 



3GPP TS 24.237 version 11.6.0 Release 11 314 ETSI TS 124 237 V11.6.0 (2013-04) 



To: <tel:+l-987-654-3210> 

Call-ID: asdfgqwerq 

Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 5 7 >; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Target -Dialog: ksdj fhwrklf; remote- tag=676723565 ; local- tag=45418454 

Require : tdialog 

Content-Length: (...) 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 

Route : <sip : atcf 2 . visited2 .net; lr> 

--boundaryl 

Content-Type: application/sdp 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

a=sendonly 

--boundaryl 

Content-Type : application/vnd . 3gpp . srvcc-ext+xml 

<?xml version="l . 0" ?> 

<srvcc-ext> 

<Setup-info> 

<C-MSISDN>tel: +1-212- 555 -1111</C-MSISDN> 

<direction>initiator</direction> 
</Setup-inf o> 
</srvcc-ext> 
- -boundaryl- - 



Request-URI: contains the ATCF URI as received in the Refer-To header field in the SIP REFER request. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

application/vnd.3gpp.srvcc-ext+xml: Contains the direction of call and the C-MSISDN of the UE. 

29. ATCF configures the ATGW 

Upon receiving the SIP INVITE request to it, the ATCF decides to anchor the ATGW, and configures the 
ATGW. Then the ATGW return the ACK to complete the configuration. 

30-31. SIP INVITE request (ATCF to SCC AS via I/S-CSCF) -see example in table A.18.5-33 

The ATCF sends the SIP INVITE request to the I/S-CSCF. The I/S-CSCF forwards the SIP INVITE request to 
the SCC AS. 

NOTE: ATCF uses the same procedure as in subclause A.4.3. 

Table A.18.5-33: SIP INVITE request (ATCF to SCC AS via I/S-CSCF) 



INVITE sip 


additional . 


session 


.xf 


=r 


pscssrvccOsccas 


homel 


net 


SIP/2.0 


Via: SIP/2 


0/UDP atcfl 


.homel . 


net 


;branch= 


z9hG4bk731b87 






Max-Forwards: 70 
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Privacy: none 

From: 

To: 

Call-ID: asdfgqwerq2 

Cseq: 

Supported: 

Accept-Contact : 

P-Asserted-Service : 

Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type : 

Target-Dialog : 

Require: tdialog 

Content-Length: (...) 



32. SIP re-INVITE request (SCC AS towards UE C) 

33. SIP 200 (OK) response to the SIP re-INVITE request (UE C towards SCC AS) 
32. SIP ACK request (SCC AS towards UE C) 

35-36. SIP 200 (OK) response (SCC AS to ATCF via I/S-CSCF) 

The SCC AS sends the SIP 200 (OK) response to the SIP INVITE to the I/S-CSCF, and the I/S-CSCF forwards 
it to the ATCF. 

37. SIP 200 (OK) response to the SIP INVITE request (ATCF to MSC server) 

38-40. SIP ACK request (MSC server to SCC AS via I/S-CSCF) 

The MSC server generates the SIP ACK request to the SIP 200 (OK) response, and sends the SIP ACK request 
to the I/S-CSCF. Then the I/S-CSCF forwards it to the SCC AS. 

41-43. SIP BYE request (SCC AS towards SC UE A via I/S-CSCF, ATCF and P-CSCF) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request towards the UE A which received by P-CSCF. 

44-46. SIP 200 (OK) response (P-CSCF to SCC AS via ATCF and I/S-CSCF) 

Upon receiving the SIP BYE request over the old IP -CAN, the P-CSCF sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. 
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A.18.6 Signalling flows for PS to CS Access Transfer: PS to CS 
SRVCC enhancements using ATCF and session traverses 
IBCF 

The signalling flow shown in figure A. 18.6-1 gives an example for PS to CS access transfer when using PS to CS 
SRVCC. The call is established, contains active speech media component and has been anchored in ATGW, and 
traverses IBCF during the establishment of the call. There are IBCFs between ATCF and SCC AS, e.g. UE A is 
roaming in another network. When PS to CS SRVCC enhancements using ATCF is triggered, the session trasfer 
notification message initiated by ATCF using ATU-STI may traverse different IBCF(s) comparing to previous signaling 
path duing the initial session set up between ATCF and SCC AS. 
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NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
Figure A.18.6-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a 

call. 

1. The UE A has a session with active speech media component with UE B 

UE A has an active session with remote UE B, media is anchored in ATGW and the session traverses IBCFl. 

2. SIP INVITE request (MSC server to ATCF)-see example in table A.18.5-2 

Table A.18.6-2: SIP INVITE request (MSC server to ATCF) 



INVITE tel: +1-237-555-3333 SIP/2.0 
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via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel : +1-237- 555-2222 > 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555- llll>;tag=171828 

To: <tel: +l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490334 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 5 7 >; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

3. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF sends the SIP 200 OK response to the MSC server with the media information allocated by the 
ATGW during session establish procedure. In the SIP 200 OK response, the ATCF includes the Record-Route 
header field containing its SIP URI that indicate where the ATCF expect to receive the indialog request sent by 
the MSC. In the Contact header field, the ATCF inserts the saved URI of the UE B that the UE A received from 
the UE B when the IP bearer between the UE A and the UE B was established. 

4. SIP ACK request (MSC server to ATCF) 

5. The new CS media between UA and MSC Server/MGW is established, and the PS media between MSC 
Server/MGW and ATCF/ATGW is established. 

6-7. SIP INVITE request (ATCF to SCC AS)-see example in table A.18.6-6 

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a 
new SIP INVITE request to the SCC AS using the stored ATU-STI. And the new dialog traverses IBCF2. The 
ATCF updates the SCC AS via the new dialog indicating that the transfer has taken place. 

Table A.18.6-6: SIP INVITE request (ATCF to SCC AS) 



INVITE sip:AUT-STIl@sccas. homel.net SIP/2.0 

via: SIP/2. 0/UDP atcf .visited2 .net :5060;branch=z9hG4bk731b87 

Max-Forwards: 70 

P- Asserted- Identity: <tel : +1-237- 555-2222 > 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ;orig-ioi=visitl .net 

Privacy: none 

From: <tel: +1-237- 555- 3333 >;tag=1888828 

To: <tel: +l-237-555-4444> 

Call -ID: Cb03a0s09a2sdfglkj 490444 

Cseq: 127 INVITE 
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Supported: lOOrel, precondition, gruu 

Require: tdialog, 

Record- Route : <sip : atcf . visited2 .net:5060;lr> 

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321 ; local-tag=64727891 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mscl .visit 1 .net : 13 5 7 >; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ggg 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ggg 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: contains the ATU-STI, that resolves (e.g. via DNS access) to the IP address of the I-CSCF. 

Target-Dialog: specifies that the existing dialog is related with this request. 

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request from 
the sec AS. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

SDP: the media information at ATGW. 

8. SIP re-INVITE request (SCC AS to UE-B) 

When the SCC AS receives the SIP INVITE from ATCF, since the SDP is different with the one in old session, 
the SCC AS performs the remote leg update with sending a SIP re-INVITE to remote UE B. 

9. SIP 200 OK reponse (UE B to SCC AS) 

10. SIP ACK request (SCC AS to UE B) 

11-12. SIP 200 OK response (SCC AS to ATCF) 

13-14. SIP ACK request (ATCF to SCC AS) 

15. There are old PS media and new PS media between ATCF and remote UE B at the same time. Therefore 
there is no session break due to remote leg update. 

16-18. SIP BYE request (SCC AS to UE A) 

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request 
to the UE A. In this case, it's assumed that the SIP BYE request go to UE A. 

19-21. SIP 200 (OK) response (UE A to SCC AS) 

Upon receiving the SIP BYE request, the UE A sends a SIP 200 (OK) response to the SCC AS. Subsequently, 
the UE A relinquishes all resources pertaining to the old IP -CAN. 
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22. After the PS to CS session transfer is completed, a new CS media between UA and MSC Server/MGW is 
established, and the PS media between MSC Server/MGW and ATCF/ATGW is established, and a new 
PS media between ATCF/ATGW and UE B is established. 



A.19 Signalling flows for vSRVCC 
A. 19.1 Introduction 

The signalling flows in this subclause demonstrate how a session consisting of active speech and video media 
components is transferred from PS to CS using vSRVCC procedures. 

A.I 9.2 Session transfer for active call with speech and video using 
vSRVCC procedure: PS to CS 

In the example flow in figure A. 19.2-1, the SC UE A has an ongoing session anchored at SCC AS, with only active 
speech and video media components and the SC UE has an ongoing session anchored at the SCC AS with only inactive 
speech media component. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN 
decides to trigger a Single Radio handover from PS to CS access. 
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CN subsystem 
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UEB 



1 . SC UE A has an active speech and video session and a held speech only session anchored at SCC AS. 
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Figure A.I 9.2-1 : PS-CS vSRVCC for an ongoing speech and video session 
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1. SC UE A has an active speech and video session and a held speech-only session 

The UE has an session containing only active speech and video media components, and a session containing 
only inactive speech media component. The corresponding multimedia PS bearer extends between UE A and UE 
B via intermediate IM CN entities. 

2. Interaction between UE, E-UTRAN, MME and MSC 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger a Single Radio 
handover from PS to CS access (as specified in 3GPP TS 23.216 [5]). The MME sends a PS to CS Request 
message, containing an vSRVCC indication and STN-SR, via Sv to the MSC. 

3. SIP OPTIONS request (MSC server to intermediate IM CN subsystem entities) - see example in 
table A.19.2-1 

The MSC has no prior knowledge whether the most recently made active session is a session with audio and 
video media or a session with only audio media. The receipt of the vSRVCC indication over the Sv interface is 
the trigger for the MSC server to send a SIP OPTIONS request for the purpose of determining the session that 
was made active most recently. 

Table A.19.2-1 : SIP OPTIONS request (MSC server to intermediate IM CN subsystem entities) 



OPTIONS tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.visitl.net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity: <tel : +1-237- 555- 1111> 

From: <tel: +1-237- 555 -llll>;tag=171828 

To: tel:+l-237-555-3333 



Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 
Contact : sip :mscl .visit 1 .net 
Accept: application/sdp; 
Content-Length: 



4. SIP OPTIONS request (intermediate IM CN subsystem entities to SCC AS) 

The SIP OPTIONS request is routed towai'ds the SCC AS. 

5. Determination of session that was made active most recently 

The SCC AS determines the session that was made active most recently, based on the C-MSISDN in the P- 
Asserted-Identity header field. 

6. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response, with an SDP body containing "m=" lines for audio and video, as 
the session that was made active most recently is a session with both audio and video media. The contents of the 
SIP 200 (OK) allow the MSC server to determine how to populate the SDP oOffer in the INVITE for STN-SR 
(see Step 8). 

Table A.19.2-2: SIP 200 (OK) (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 


200 OK 






Via: SIP/2. 0/UDP mgcfl.visitl 


net 


branch=z9hG4bk731b8 7 


From: <tel:+l-237-555-3333> 






To: <tel:+l-237-555-llll>;tag= 


= 314159 


Call-ID 


Cb0 3a0s0 9a2sdfglkj4 90 3 34 




Content 


-Type: application/sdp 






Content 


-Length: (...) 






m=audio 


3456 RTP/AVP 97 96 






m=video 


3400 RTP/AVP 98 99 







7. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MSC server. 

8. SIP INVITE (MSC server to Intermediate IM CN subsystem entities) 
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The MSC server sends a SIP INVITE for STN-SR with the following parameter settings: 

Request-URI: contains the STN-SR 

SDP: contains only a speech media component and a video media component with default codecs for speech 
and video (as specified in 3GPP TS 26. Ill [69]) 

Contact: contains the address of the MSC server. 

9. SIP INVITE (Intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE is forwarded to the SCC AS with parameters listed in step 8 unchanged. 

10. Update of the remote leg 

The SCC AS performs SIP signaling (re-INVITE) for the purpose of updating the remote leg (UE B) with new 
contact information (for signaling and media). 

11. and 12. SIP 200 (OK) response (SCC AS via Intermediate IM CN subsystem entities to MSC server) 

The SCC AS acknowledges the receipt of the INVITE received in step 8. The SIP acknowledgement is 
forwarded to the MSC server. 

13. and 14. SIP ACK (MSC server via Intermediate IM CN subsystem entities to SCC AS) 

The MSC server sends a SIP acknowledgement to the Intermediate IM CN subsystem entities; it is forwarded to 
the SCC AS. 

15. and 16. SIP BYE request (SCC AS via intermediate IM CN subsystem entities to UE) 

The SCC AS releases the source access. 
17. and 18. SIP 200 (OK) response (UE to SCC AS via Intermediate IM CN subsystem entities) 

The UE acknowledges the release of the source access leg. 

19. UE attaches in CS and sets up a data call 

The UE attaches in the CS domain and establishes a data call based on a BS30 bearer, as described in 
3GPP TS 24.008 [8]. The UE replaces the session with active speech and video media components with the 
newly established CS video call. 

A.20 Signalling flows for CS to PS Access Transfer: using 
CS to PS SRVCC 

A.20.1 Introduction 

The signalling flows in the subclause demonstrate the CS to PS access SRVCC transfer. The following signalling flows 
are included: 

subclause A. 20. 2 shows an example of CS to PS access transfer for SRVCC when CS to PS SRVCC occurs 
during an ongoing call for which media are anchored in ATGW. 

subclause A.20. 3 shows an example of CS to PS access transfer for SRVCC when CS to PS SRVCC occurs 
during an ongoing call for which media are not anchored in ATGW. 
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A.20.2 Signalling flows for CS to PS Access Transfer: CS to PS 
SRVCC occurs during an active call 

The signalling flow shown in figure A.20.2-1 gives an example for CS to PS access transfer when using CS to PS 
SRVCC. The call is established, contains active speech media component and has been anchored in ATGW during the 
establishment of the call. 

The call may have been established either via the MSC server or as the result of the CS to PS SRVCC procedure. 
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NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
Figure A.20.2-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a 

call. 

1+2. The UE A has an session with active speech media component with UE B 

There is one CS bearer between the UE A and the MSC server, one PS bearer between the MSC server and the 
ATGW and one PS bearer between the ATGW and the remote end UE B. The CS call has the transaction 
identifier 88 (decimal) and was originated by UE B and accepted by UE A. 
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3. The UE A sends the measurement reports to E-UTRAN that decides to trigger a CS to PS SRVCC 
handover to the E-UTRAN access. 

4. CS to PS request 

The MSC server receives a CS to PS request indicating that a CS to PS SRVCC access transfer is initiated. 

5. SIP INFO request (MSC server to ATCF) - see example in table A.20.1-5 

The MSC Server initiates the CS to PS SRVCC by means of a SIP INFO request sent towards the ATCF. The 
SIP INFO includes a session transfer notification request. The session transfer notification request is an 
indication to prepare for the transfer of media to PS. 

Table A.20.2-5: SIP INFO request (MSC server to ATCF) 



INFO sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : atcf .visited.net ; lr>, <sip : scscf .homel .net ; lr>, <sip : icscf .homel .net ; lr>, 

<sip: sccas .homel .net; lr> 
From: <tel:+l-212-555-2222>;tag=17182 8 
To: <sip :userl_publicl®homel .net>; tag=171828 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 130 INFO 

Info-Package : g . 3gpp . access-transfer-events 
Content-Disposition : Info-Package 

Content-Type : application/vnd . g . 3gpp . access-transf er-events+xml 
Content-Length: (...) 

<?xml version="l . 0" ?> 

< event s> 

<event event-type="l"/> 

</events> 



application/vnd.3gpp.access-transfer-events+xml: Contains the value 1 indicating that the MSC server sends the 
session transfer notification request to the ATCF. 

6 SIP 200 OK response (ATCF to MSC server) 

The ATCF acknowledge the SIP INFO request. 

7. ATCF reserves resources in ATGW 

The ATCF reserves resources in ATGW towards UE A and the ATGW provides the SDP answer to the SDP 
which the UE A provided during the registration (see subclase A.3.w). Apart from the IP address and port, the 
SDP answer contains the same media pararameters as provided to the UE A after PS registration (see subclause 
A.3.W). 

8. SIP INFO request (ATCF to MSC server) - see example in table A.20.1-8 

The ATCF sends a SIP INFO request containing the session transfer notification response contains the 
parameters required for the transfer, including IP address and media port allocated in the ATGW. 
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Table A.20.2-8: SIP INFO request (ATCF to MSC server) 



INFO sip:userl_publicl®visited2 .net SIP/2.0 

Via: 

Max- Forwards : 

Record-Route : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Disposition : Info-Package 

Info-Package : g . 3gpp . access-transfer-events 

Contact : 

Content-Type : application/vnd . 3gpp . access-transf er-events+xml 

Content-Length: (...) 

<?xml version="l . 0" ?> 
< event s> 

<event event-type="2" > 
<STNResp-params> 

<transfer-details>AVLOIrgAAAAAAAAAbwDeAUOBvA==</transfer-details> 
<redirect-speech>f alse< /redirect -speech> 
</STNResp-params> 
< /event > 
</ event s> 



application/vnd.3gpp.access-transfer-events+xml: Contains the IPv6 address and port number of the ATGW. 
With the following <transfer-details>: ATGW-IPv6-address = 8888:: 111:222:333:444, ATGW- 
audio-UDP-port = 21236. Also indicates that the ATCF does not require the MSC server to 
redirect the speech media component of the session transferred by the CS to PS SRVCC access 
transfer. 

Info-Package: Indicates that the SIP INFO request contains the g.3gpp.access-transfer-events info package. 

9. SIP 200 OK response (MSC server to ATCF) 
The MSC server acknowledge the SIP INFO request. 

10. The MSC server starts the preparation for the access transfer. 

11. When access transfer is prepared, the MSC server sends CS to PS handover command to the UE using 
access stratum signalling. 

12. SIP INFO request (MSC server to ATCF) - see example in table A.20.1-12 

The MSC server sends a SIP INFO request containing a session transfer preparation to the ATCF to instruct the 
ATCF that media should be switched to the target access. 

Table A.20.2-12: SIP INFO request (MSC server to ATCF) 



INFO sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : atcf .visited.net ; lr>, <sip : scscf .homel .net ; lr>, <sip : icscf .homel .net ; lr>, 

<sip: sccas .homel .net; lr> 
From: <tel:+l-212-555-2222>;tag=17182 8 
To: <sip :userl_publicl@homel .net>; tag=171828 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 130 INFO 

Content-Disposition : Info-Package 
Info-Package : g . 3gpp . access-transfer-events 

Content-Type : application/vnd . 3gpp . access-transf er-events+xml 
Content-Length: (...) 

<?xml version="l . 0" ?> 

< event s> 

<event event-type="3"/> 

</events> 
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application/vnd.3gpp.access-transfer-events+xml: Contains the event 3 indicating that MSC server requests 

ATCF to perform the CS to PS SRVCC access transfer, i.e. start sending media towards the UE 
instead of towards the MSC server. 

13. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF acknowledge the SIP INFO request by means of a SIP 200 (OK) respons. 

14. ATCF configures resources in ATGW 

The ATCF configures resources in the ATGW to start sending and receiving media towards the UE A instead of 
the MSC server. 

15. The media path is now reconfigured. The audio is sent between the UE A and ATGW using IMS 
signalUng bearer. 

16-17. SIP INVITE request (UE A to ATCF) - see example in table A.20.1-16 

When the UE A receives the CS to PS handover command the UE A sends an SIP INVITE request towards the 
ATCF. 

Table A.20.2-16: SIP INVITE request (UE A to ATCF) 



INVITE sip: sti-rsr@atcf 1 .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visited2 .net : 75 31; lr;comp=sigcomp>, < sip : atcf .visited.net ; Ir, 
<sip:orig@scscf 1 .homel .net ; lr> 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 
c=8642; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Accept -Contact : * ;+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

Accept : application/sdp, application/3gpp-ims+xml 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a = r tpmap :96 telephone- event 



Request-URI: contains the STI-rSR associated with the transferred call. 

SDP offer: The media parameters of the speech media component are the same as the UE A sent to ATCF 

during registraton (see subclause A.3.w). 

18. SIP 200 (OK) response (ATCF to P-CSCF)- see example in table A.20.1-18 

The ATCF sends the SIP 200 (OK) response towards the UE A with the media information allocated by the 
ATGW. 
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Table A.20.2-18: SIP 200 (OK) response (ATCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Record- Route : <sip :pcscf 1 . visited2 .net : 75 31; lr;comp=sigcomp>, <sip : atcf .visited.net; lr> 
P- Asserted- Identity: <tel:+l-212-555-2222> 
Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 
To: <tel : +1-212 -555 -2222 >;tag=aaaa 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Feature -Caps : *;+g. 3gpp . ti="70D8" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a = r tpmap :96 telephone- event 



Feature-Caps: g.3gpp.ti feature-capability indicator with value containing the transaction identifier specified in 
figure 11.9 and table 11.3 of 3GPP TS 24.007 [75] encoded by hexadecimal digit. In this example, 
the transaction identifier 88 (decimal) and the transaction identifier flag as sent by the MSC server 
in CS signalling of the terminating CS call are shown. 

19. Bearer resource reservation 

P-CSCF initiates bearer resource reservation based on the SDP answer received in the SIP 200 (OK) response. 

20. SIP 200 (OK) response (P-CSCF to UE A) 

The P-CSCF forwards the SIP 200 (OK) response to the UE A. The UE A associates the dialog established by 
the SIP 200 (OK) response with the CS call where the transaction identifier sent by MSC server were equal to 
the value of the g.3gpp.ti feature-capability indicator in the Feature-Caps header field of the SIP 200 (OK) 
response. 

21-22. SIP ACK request (UE A to ATCF) 

The UE A acknowledges the reception of the SIP 200 (OK) response. 

23. The media path is now reconfigured. The audio is sent between the UE A and ATGW using a dedicated 
bearer. 

24-25. SIP INVITE request (ATCF to SCC AS) - see example in table A.20.1-25 
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Table A.20.2-25: SIP INVITE request (ATCF to SCC AS) 



INVITE sip:cs2ps@sccasl .homel .net SIP/2.0 
Record- Route : <sip : atcf 2 . visited2 .net; lr> 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas55889 , SIP/2. 0/UDP 

[5555: :aaa:bbb:ccc:ddd] :13 57; ;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : orig@scscf 1 . homel . net ; lr> 
P- Asserted- Identity: <tel : +l-212-555-llll> 
P- Charging- Vector: icid-value="12 34bc9876e" ; icid-generated-at"5555 : : aaa :bbb : ccc :ddd" ;orig- 

ioi=visited2 .net 
P-Pref erred-Service : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Proxy-Require : 
Contact : 
Accept-Contact : 
Allow: 

Content-Type : 
Content-Length : 
Accept : 

v=0 

o=- 22 333 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 8899 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



Request-URI: contains the ATU-STI for CS to PS SRVCC associated with the transferred call. 

SDP: The SDP contains the SDP used at ATGW towards the remote UE B. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

26-27. SIP 200 (OK) response (SCC AS to ATCF) 

Since there is no update in the session description, no remote end update will be performed. The SCC AS sends 
confirmation response to the ATCF which contains the SDP answer that the SCC AS stored during the original 
session establishment procedure. 

28-29. SIP ACK request (ATCF to SCC AS) 

30-32. SIP BYE request (SCC AS to MSC server) 

The SCC AS initiates the release of the source access leg. 
33-35. SIP 200 (OK) response (MSC server to UE A) 

36. The MSC server clears the call 

The MSC server locally clears the call. 

37. The UA A clears the call 
The UA locally clears the call. 
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A.20.3 Signalling flows for CS to PS Access Transfer without CS 
media anchored in ATGW: CS to PS SRVCC occurs during 
an active call 

The signalling flow shown in figure A.20.3-1 gives an example for CS to PS access transfer when using CS to PS 
SRVCC. The call is established, contains active speech media component and has not been anchored in ATGW during 
the establishment of the call. 

The call may have been established either via the MSC server or as the result of the CS to PS SRVCC procedure. 
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1. UE A IS on an active session with UE B through the CS network. The media is not anchored at ATGW. The active call may have been 
initiated by the UE A or UE B or the result of a PS to CS SRVCC procedure. 
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NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
Figure A.20.3-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a 

call. 

1+2. The UE A has an session with active speech media component with UE B 

There is one CS bearer between the UE A and the MSC server, one PS bearer between the MSC server and the 
remote end UE B. The CS call has the transaction identifier 88 (decimal) and was originated by UE B and 
accepted by UE A. 
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3. The UE A sends the measurement reports to E-UTRAN that decides to trigger a CS to PS SRVCC 
handover to the E-UTRAN access. 

4. CS to PS request 

The MSC server receives a CS to PS request indicating that a CS to PS SRVCC access transfer is initiated. 

5. SIP INFO request (MSC server to ATCF) - see example in table A.20.3-5 

The MSC Server initiates the CS to PS SRVCC by means of a SIP INFO request sent towards the ATCF. The 
SIP INFO includes a session transfer notification request. The session transfer notification request is an 
indication to prepare for the transfer of media to PS. 

Table A.20.3-5: SIP INFO request (MSC server to ATCF) 



INFO sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : atcf .visited.net ; lr>, <sip : scscf .homel .net ; lr>, <sip : icscf .homel .net ; lr>, 

<sip: sccas .homel .net; lr> 
From: <tel:+l-212-555-2222>;tag=17182 8 
To: <sip :userl_publicl®homel .net>; tag=171828 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 130 INFO 

Content-Disposition : Info-Package 
Info-Package : g . 3gpp . access-transfer-events 

Content -Type : application/vnd.g. 3gpp . access -transfer- event s+xml 
Content-Length: (...) 

<?xml version="l . 0" ?> 

< event s> 

<event event-type="l"/> 

</events> 



application/vnd.3gpp.access-transfer-events+xml: Contains the value 1 indicating that the MSC server sends the 
session transfer notification request to the ATCF. 

6 SIP 200 OK response (ATCF to MSC server) 

The ATCF acknowledge the SIP INFO request. 

7. ATCF reserves resources in ATGW 

The ATCF reserves resources in ATGW towards UE A and the ATGW provides the SDP answer to the SDP 
which the UE A provided during the registration (see subclase A.3.w). Apart from the IP address and port, the 
SDP answer contains the same media pararameters as provided to the UE A after PS registration (see subclause 
A.3.W). 

8. SIP INFO request (ATCF to MSC server) - see example in table A.20.3-8 

The ATCF sends a SIP INFO request containing the session transfer notification response contains the 
parameters required for the transfer, including IP address and media port allocated in the ATGW. 
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Table A.20.3-8: SIP INFO request (ATCF to MSC server) 



INFO sip:userl_publicl®visited2 .net SIP/2.0 

Via: 

Max- Forwards : 

Record-Route : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Disposition : Info-Package 

Info-Package : g . 3gpp . access-transfer-events 

Contact : 

Content-Type : application/vnd . 3gpp . access-transf er-events+xml 

Content-Length: (...) 

<?xml version="l . 0" ?> 
< event s> 

<event event-type="2" > 
<STNResp-params> 

<transfer-details>AVLOIrgAAAAAAAAAbwDeAUOBvA==</transfer-details> 
<redirect-speech>true</redirect-speech> 
</STNResp-params> 
< /event > 
</ event s> 



application/vnd.3gpp.access-transfer-events+xml: Contains the IPv6 address and port number of the ATGW. 
With the following <transfer-details>: ATGW-IPv6-address = 8888:: 111:222:333:444, ATGW- 
audio-UDP-port = 21236. Also indicates that the ATCF requires the MSC server to redirect the 
speech media component of the session transferred by the CS to PS SRVCC access transfer. 

Info-Package: Indicates that the SIP INFO request contains the g.3gpp. access-transfer-events info package. 

9. SIP 200 OK response (MSC server to ATCF) 
The MSC server acknowledge the SIP INFO request. 

10. The MSC server starts the preparation for the access transfer. 

11. SIP INVITE request (MSC server to ATCF) - see example in table A.20.3-11 

The MSC sends a SIP INVITE request to the ATCF to instruct the ATCF to establish the media bearer between 
MOW and ATGW. 

Table A.20.3-11 : SIP INVITE request (MSC server to ATCF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route: <sip : atcf .visited.net ; lr>, <sip : scscf .homel .net ; lr>, <sip : icscf .homel .net ; lr>, 
<sip: sccas .homel .net ; lr> 

From: <tel:+l-212-555-2222>;tag=17182 8 

To : <sip :userl_publicl®homel .net>; 

Call-ID: Cb03a0s0 9a2sdfglkj4 90333 

Contact : <sip :mscl .homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6>; +g. 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Cseq: 1 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 



12. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF acknowledge the SIP INVITE request by means of a SIP 200 (OK) respons. 

13. SIP ACK request (MSC Server to ATCF) 

The MSC Server acknowledges the reception of the SIP 200 (OK) response. 
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14. When access transfer is prepared, the MSC server sends CS to PS handover command to the UE using 
access stratum signalling. 

15. The MSC Server instructs the MGW to switch the media path from the source access to the target access. 

16. SIP INFO request (MSC server to ATCF) - see example in table A.20.3-16 

The MSC server sends a SIP INFO request containing a session transfer preparation to the ATCF to instruct the 
ATCF that media should be switched to the target access. 

Table A.20.3-16: SIP INFO request (MSC server to ATCF) 



INFO sip:user2_publicl®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] :1357; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : atcf .visited . net ; lr> , <sip : scscf .homel .net ; lr>, <sip : icscf .homel .net ; lr>, 

<sip: sccas .homel .net ; lr> 
From: <tel:+l-212-555-2222>;tag=17182 8 
To: <sip :userl_publicl®homel .net>; tag=171828 
Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 33 
Cseq: 130 INFO 

Content-Disposition : Info-Package 
Info-Package : g . 3gpp . access-transfer-events 

Content-Type : application/vnd . 3gpp . access-transf er-events+xml 
Content-Length: (...) 

<?xml version="l . 0" ?> 

< event s> 

<event event-type="3"/> 

</events> 



application/vnd.3gpp.access-transfer-events+xml: Contains the event 3 indicating that MSC server requests 

ATCF to perform the CS to PS SRVCC access transfer, i.e. start sending media towards the UE 
instead of towards the MSC server. 

17. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF acknowledge the SIP INFO request by means of a SIP 200 (OK) respons. 

18. ATCF configures resources in ATGW 

The ATCF configures resources in the ATGW to start sending and receiving media towards the UE A instead of 
the MSC server. 

19. The media path is now reconfigured. 

20-21. SIP INVITE request (UE A to ATCF) - see example in table A.20.3-20 

When the UE A receives the CS to PS handover command the UE A sends an SIP INVITE request towards the 
ATCF. 
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Table A.20.3-20: SIP INVITE request (UE A to ATCF) 



INVITE sip: sti-rsr@atcf 1 .visited2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visited2 .net : 75 31; lr;comp=sigcomp>, < sip : atcf .visited.net ; Ir, 
<sip:orig(ascscf 1 .homel .net ; lr> 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel: +1-212- 555- llll>;tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec -agree 

Supported: lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 
c=8642; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Accept: application/sdp; application/3gpp-ims+xml 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

Accept : application/sdp, application/3gpp-ims+xml 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: contains the STI-rSR associated with the transferred call. 

SDP offer: The media parameters of the speech media component are the same as the UE A sent to ATCF 

during registration (see subclause A.3.w). 

22. SIP 200 (OK) response (ATCF to P-CSCF) - see example in table A.20.3-22 

The ATCF sends the SIP 200 (OK) response towards the UE A with the media information allocated by the 
ATGW. 
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Table A.20.3-22: SIP 200 (OK) response (ATCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Record- Route : <sip :pcscf 1 . visited2 .net : 75 31; lr;comp=sigcomp>, <sip : atcf .visited.net; lr> 
P- Asserted- Identity: <tel:+l-212-555-2222> 
Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 
To: <tel : +1-212 -555 -2222 >;tag=aaaa 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Feature -Caps : *;+g. 3gpp . ti="70D8" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a = r tpmap :96 telephone- event 



Feature-Caps: g.3gpp.ti feature-capability indicator with value containing the transaction identifier specified in 
figure 11.9 and table 11.3 of 3GPP TS 24.007 [75] encoded by hexadecimal digit. In this example, 
the transaction identifier 88 (decimal) and the transaction identifier flag as sent by the MSC server 
in CS signalling of the terminating CS call are shown. 

23. Bearer resource reservation 

P-CSCF initiates bearer resource reservation based on the SDP answer received in the SIP 200 (OK) response. 

24. SIP 200 (OK) response (P-CSCF to UE A) 

The P-CSCF forwards the SIP 200 (OK) response to the UE A. The UE A associates the dialog established by 
the SIP 200 (OK) response with the CS call where the transaction identifier sent by MSC server were equal to 
the value of the g.3gpp.ti feature-capability indicator in the Feature-Caps header field of the SIP 200 (OK) 
response. 

25-26. SIP ACK request (UE A to ATCF) 

The UE A acknowledges the reception of the SIP 200 (OK) response. 

25. The media path is now reconfigured. The audio is sent between the UE A and ATGW using a dedicated 
bearer. 

27-28. SIP INVITE request (ATCF to SCC AS) - see example in table A.20.3-27 
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Table A.20.3-27: SIP INVITE request (ATCF to SCC AS) 



INVITE sip:cs2ps@sccasl .homel .net SIP/2.0 
Record- Route : <sip : atcf 2 . visited2 .net; lr> 
Via: SIP/2. 0/UDP atcf .visited2 . net : 5060 ;branch=z9hG4bKnas55889 , SIP/2. 0/UDP 

[5555: :aaa:bbb:ccc:ddd] :13 57; ;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : orig@scscf 1 . homel . net ; lr> 
P- Asserted- Identity: <tel : +l-212-555-llll> 
P- Charging- Vector: icid-value="12 34bc9876e" ; icid-generated-at"5555 : : aaa :bbb : ccc :ddd" ;orig- 

ioi=visited2 .net 
P-Pref erred-Service : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Proxy-Require : 
Contact : 
Accept : 

Accept-Contact : 
Allow: 

Content-Type : 
Content-Length : 
Accept : 

v=0 

o=- 22 333 IN IP6 8888 :: 111 : 222 : 333 : 444 

s = - 

C=IN IP6 8888 : :111:222 :333 :444 

t = 

m=audio 8899 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: contains the ATU-STI for CS to PS SRVCC associated with the transferred call. 

SDP: The SDP contains the SDP used at ATGW towards the remote UE B. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

29-30. SIP 200 (OK) response (SCC AS to ATCF) 

Since there is update in the session description, remote end update will be performed. The SCC AS sends 
confirmation response to the ATCF which contain the SDP answer that the SCC AS recevied during remote end 
update procedure. 

31-32. SIP ACK request (ATCF to SCC AS) 

33. SIP BYE request (ATCF to MSC Server) 

Upon receiving the SIP 200(OK) response from SCC AS, the ATCF sends a SIP BYE request to MSC Server to 
release the session established by SIP INVITE requet in step 1 1 . 

34. SIP 200 (OK) response (MSC Server to ATCF) 

MSC server sends the SIP 200 (OK) response to the ATCF. 
35-37. SIP BYE request (SCC AS to MSC server) 

The SCC AS initiates the release of the source access leg. 
38-40. SIP 200 (OK) response (MSC server to UE A) 

41. The audio is sent between the UE A and ATGW using a dedicated PS bearer. 

42. The MSC server clears the call 
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The MSC server locally clears the call. 
43. The UA A clears the call 

The UA locally clears the call. 



£75/ 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 336 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 



Annex B (informative): 
Void 
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Annex C (normative): 

Media feature tags and feature-capability indicators defined 

within the current document 

C.1 General 

This subclause describes the media feature tag definitions and the feature-capabihty indicators definitions that are 
appHcable for the 3GPP IM CN Subsystem for the reahsation of the MSC server assisted mid-call feature. Access 
Transfer Control Function, and PS to CS SRVCC for calls in alerting phase. 

C.2 Definition of media feature tag g.Sgpp. mid-call 

Media feature-tag name: g.3gpp. mid-call 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP request or a SIP response 
indicates that the function sending the SIP message supports the MSC server assisted mid-call feature. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a conmiunications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the MSC server assisted mid-call feature 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 



C.2A Definition of feature-capability indicator g.Sgpp. mid- 
call 

Editor's note [eSRVCC-naSRVCC, CR#0713]: this feature-capability indicator is to be registered with IAN A after 
the draft-ietf-sipcore-proxy-feature becomes RFC 

Feature-capability indicator name: g.3gpp. mid-call 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when used in a Feature-Caps header field of a SIP request or a SIP response indicates 
that: 

1 . the functional entity including the feature-capability indicator in the SIP message supports the MSC server 
assisted mid-call feature; and 

2. all entities of which the functional entity including the feature-capability indicator in the SIP message is aware of 
being requested to support the feature do support the MSC server assisted mid-call feature. 

Feature-capability indicator specification reference: 
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3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: none 

Examples of typical use: Indicating that a network entity supports the MSC server assisted mid-call feature. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 



C.3 Void 

C.4 Definition of feature-capability indicator g.Sgpp.atcf 

Editor's note: [WID eSRVCC, CR#0353] this feature-capability indicator is to be registered with lANA after the 
draft-ietf-sipcore-proxy-feature becomes RFC 

Feature-capability indicator name: g.3gpp.atcf 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when included in a Feature-Caps header field as specified in IETF RFC 6809 [60] in a 
SIP REGISTER request or a SIP response to the SIP REGISTER request indicates presence and support of a resource 
which is an Access Transfer Control Function (ATCF) and also the session transfer number allocated to the ATCF. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: 

None or string with an equality relationship. When used in a Feature-Caps header field in SIP REGISTER request or 
response, the value is string containing the session transfer number allocated to the ATCF following the syntax as 
described in table C.4-1 for g-3gpp-atcf-in-path. 

Table C.4-1 : ABNF syntax of values of the g.Sgpp.atcf feature-capability indicator 

g-3gpp-atcf-in-path = STN-SR 
STN-SR = "<" addr-spec ">" 

The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or 
negotiation mechanisms: This feature-capability indicator is used to indicate support of the ATCF. 

Examples of typical use: Indicating the presence and support of an ATCF on the routing path of the SIP REGISTER 
request and SIP response to the SIP REGISTER request and providing the session transfer number allocated to this 
ATCF. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 



C.5 Definition of media feature tag g.Sgpp.srvcc-aierting 

Media feature-tag name: g.3gpp.srvcc-alerting 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN.l Identifier will need to be updated once the lANA registration is completed. 
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Summary of the media feature indicated by this tag: This media feature-tag when used in a Contact header field of a SIP 
request or a SIP response indicates that the functional entity sending the SIP message supports PS to CS SRVCC access 
transfer for calls in alerting phase, i.e. for calls whith early dialog. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a user equipment supports PS to CS SRVCC for calls in alerting phase. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 



C.5A Definition of feature-capability indicator g.Sgpp.srvcc- 
alerting 

Feature-capability indicator name: g.3gpp.srvcc-alerting 

Editor's note [eSRVCC-naSRVCC, CR#0713]: this feature-capability indicator is to be registered with lANA after 
the draft-ietf-sipcore-proxy-feature becomes RFC 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when used in a Feature-Caps header field of a SIP request or a SIP response indicates 
that: 

1. the functional entity including the feature-capability indicator in the SIP message supports access transfer for 
calls in alerting phase; and 

2. all entities of which the functional entity including the feature-capability indicator in the SIP message is aware of 
being requested to support the feature do support access transfer for calls in alerting phase. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: none 

Examples of typical use: Indicating that a network entity supports SRVCC for calls in alerting phase. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 

C.6 Definition of feature-capability indicator g.Sgpp.atcf- 
mgmt-uri 

Editor's note: [WID eSRVCC, CR#0353] this feature-capability indicator is to be registered with lANA after the 
draft-ietf-sipcore-proxy-feature becomes RFC 

Feature-capability indicator name: g.3gpp.atcf-mgmt-uri 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when used in a Feature-Caps header field as specified in IETF RFC 6809 [60] in SIP 
REGISTER request indicates presence and support of performing as a UAS for SIP requests for ATCF management 
received at this URI. 



ETSI 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 340 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: 

String with an equality relationship. When used in a Feature-Caps header field, the value is string following the syntax 
as described in table C.6-1 for g-3gpp-atcf-mgmt-uri-in-path. 

Table C.6-1 : ABNF syntax of values of the g.3gpp.atcf-mgmt-uri feature-capability indicator 

g-3gpp-atcf -mgmt-uri-in-path = "<" SIP-URI ">" 



The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or 
negotiation mechanisms: This feature-capability indicator is used to indicate the management URI of the ATCF for 
receiving SIP requests where the ATCF performs the UAS role. 

Examples of typical use: Indicating the management URI of the ATCF for SIP requests containing PS to CS SRVCC 
related information. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 



C.7 Definition of feature-capability indicator g.Sgpp.srvcc 

Feature-capability indicator name: g.3gpp.srvcc 

Editor's note [eSRVCC, CR#0470]: this feature-capabiUty indicator is to be registered with IAN A after the draft- 
ietf-sipcore-proxy-feature becomes RFC 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capabiUty indicator when included in a Feature-Caps header field as specified in IETF RFC 6809 [60] of: 

- a SIP INVITE request; or 

- a SIP INVITE response; 

indicates presence and support of a resource capable of performing the PS to CS SRVCC access transfer procedure as 
specified in 3GPP TS 24.237. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: none 

The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or 
negotiation mechanisms: This feature-capability indicator is most useful in a communications application for indicating 
that a resource supports single radio voice call continuity. 

Examples of typical use: Indicating that a resource supports single radio voice call continuity. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 
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C.8 Definition of feature-capability indicator g.Sgpp.atcf- 
path 

Editor's note: [WID eSRVCC, CR#0353] this feature-capability indicator is to be registered with lANA after the 
draft-ietf-sipcore-proxy-feature becomes RFC 

Feature-capability indicator name: g.3gpp.atcf-path 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when used in a Feature-Caps header field as specified in IETF RFC 6809 [60] in SIP 
REGISTER request indicates capability of identifying the registration path and binding SRVCC related information to 
it. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: 

String with an equality relationship. When used in a Feature-Caps header field, the value is a SIP URI of ATCF, the 
ATCF URI for terminating requests, identifying the registration path following the syntax as described in table C.8-1 
for g-3gpp-atcf-path. 

Table C.8-1 : ABNF syntax of values of the g.3gpp.atcf-path feature-capability indicator 

g-3gpp-atcf-path = "<" SIP-URI ">" 



The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or 
negotiation mechanisms: This feature-capability indicator is used in access transfer control function of single radio 
voice call continuity to identify registration path so that SCC AS can provided the SRVCC related information related 
to the registration path. 

Examples of typical use: Indicating capability of identifying a registration path and binding SRVCC related information 

to it. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 



C.9 Definition of media feature tag g.3gpp.cs2ps-srvcc 

Media feature tag name: g.3gpp.cs2ps-srvcc 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note [WID rSRVCC, CR#0627]: The ASN.l Identifier will need to be updated once the IAN A registration 
is completed. 

Summary of the media feature indicated by this tag: 

This media feature tag when included in Contact header field indicates support of the CS to PS single radio voice call 
continuity as specified in 3GPP TS 24.237. 

Values appropriate for use with this feature tag: Boolean 

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature tag is most useful in a communications application for indicating that a resource supports the 
CS to PS single radio voice call continuity. 
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Examples of typical use: Indicating that a resource supports the CS to PS single radio voice call continuity. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 

C.9A Definition of feature-capability indicator 
g.3gpp.cs2ps-srvcc 

Feature-capability indicator name: g.3gpp.cs2ps-srvcc 

Editor's note [eSRVCC+aSRVCC, CR#0713J: this feature tag is to be registered with lANA after the draft-ietf- 
sipcore-proxy-feature becomes RFC 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when included in Feature-Caps header field as specified in IETF RFC 6809 [60] 
indicates support of the CS to PS single radio voice call continuity as specified in 3GPP TS 24.237. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: 

none or string with an equality relationship 

When the value is string, the value contains the session transfer identifier for CS to PS SRVCC and follows the syntax 
as described in table C.9A-1 for g.3gpp.cs2ps-srvcc-value. 

Table C.9A-1 : ABNF syntax of string values of the g.3gpp.cs2ps-srvcc feature-capability indicator 

g. 3gpp . cs2ps-srvcc-value = STI-rSR 
STI-rSR = "<" addr-spec ">" 

Examples of typical use: Indicating that a resource supports the CS to PS single radio voice call continuity. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 

C.10 Definition of media feature tag g.3gpp.mgmt-uri 

Editor's note: [WID eSRVCC, CR#0627] this feature tag is to be registered with lANA after the freezing the Rel-11 

Media feature tag name: g.3gpp.mgmt-uri 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note [WID rSRVCC, CR#0627]: The ASN.l Identifier will need to be updated once the lANA registration 
is completed. 

Summary of the media feature indicated by this tag: 

This media feature tag indicates that the resource is capable of acting as a UAS for SIP requests for the management 
received at the URI indicated in the media feature tag value. 

Values appropriate for use with this feature-tag: 

String with an equality relationship. The value follows the syntax described in table C.10-1 for g-3gpp-mgmt-uri-value. 
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Table C.10-1 : ABNF syntax of string values of the g.3gpp.mgmt-uri media feature tag 

g-3gpp-mgmt-uri-value = SIP-URI 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is used to indicate capability of being managed by other SIP entity. 

Examples of typical use: Indicate capability of being managed by other SIP entity for CS to PS single radio voice call 
continuity. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 



C.1 1 Definition of media feature tag g.Sgpp.path 

Editor's note: [WID eSRVCC, CR#0627] this feature tag is to be registered with IAN A after the freezing the Rel-Il 

Media feature-tag name: g.3gpp.path 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: [WID eSRVCC, CR#0627] The ASN.l Identifier will need to be updated once the lANA registration 
is completed. 

Summary of the media feature indicated by this tag: 

This media feature tag when used in a Contact header field in SIP REGISTER request or SIP response to the SIP 
REGISTER request indicates capability of identifying the registration path and binding SRVCC related information to 
it. 

Values appropriate for use with this feature-tag: 

String with an equality relationship. The value is the URI for terminating requests, identifying the registration path, and 
follows the syntax described in table C.11-1 for g-3gpp-path-value. 

Table C.11-1 : ABNF syntax of string values of the g.Sgpp.path media feature tag 

g-3gpp-path-value = SIP-URI 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is used in MSC server to identify registration path so that SCC AS can provided the 
SRVCC related information related to the registration path. 

Examples of typical use: Indicating capability of identifying a registration path and binding SRVCC related information 
to it. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 



C.1 2 Definition of media feature tag g.Sgpp.ti 

Editor's note: [WID rSRVCC-CT, CR#0678] this feature tag is to be registered with lANA after the freezing the 
Rel-11 

Media feature-tag name: g.3gpp.ti 
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ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: [WID rSRVCC-CT, CR#0678] The ASN.l Identifier will need to be updated once the lANA 
registration is completed. 

Summary of the media feature indicated by this tag: 

This media feature tag when used in a Contact header field as specified in IETF RFC 3840 [53] in SIP INVITE request 
or SIP response to the SIP INVITE request indicates the capability of associating a CS call with dialog created by the 
SIP INVITE request. 

Values appropriate for use with this feature-tag: 

String with an equality relationship. The value is the transaction identifier specified in figure 11. 9 and table 1 1.3 of 
3GPP TS 24.007 [75] encoded by hexadecimal digits. Each octet of the figure 1 1 .9 of 3GPP TS 24.007 [75] is encoded 
by two hexadecimal digit, first of which represents the bits 8 - 5 of the octet. The transaction identifier flag is set as sent 
by the MSC server in CS signalling of the associated CS call. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is used to indicate capability of associating a CS call with dialog created by the SIP 
INVITE request. 

Examples of typical use: Indicating capability of associating a CS call with dialog created by the SIP INVITE request. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature tag are discussed in subclause 12.1 of 
IETF RFC 3840 [53]. 



C.12A Definition of feature-capability indicator g.Sgpp.ti 

Feature-capability indicator name: g.3gpp.ti 

Editor's note [eSRVCC-naSRVCC, CR#0713]: this feature-capability indicator is to be registered with lANA after 
the draft-ietf-sipcore-proxy-feature becomes RFC 

Summary of the feature indicated by this feature-capability indicator: 

This feature-capability indicator when used in a Feature-Caps header field as specified in IETF RFC 6809 [60] in SIP 
INVITE request or SIP response to the SIP INVITE request indicates the capability of associating a CS call with dialog 
created by the SIP INVITE request. 

Feature-capability indicator specification reference: 

3GPP TS 24.237, http://www.3gpp.org/ftp/Specs/archive/24_series/24.237/ 

Values appropriate for use with this feature-capability indicator: 

String with an equality relationship. The value is the transaction identifier specified in figure 1 1.9 and table 1 1.3 of 
3GPP TS 24.007 [75] encoded by hexadecimal digits following the syntax as described in table C.12A-1 for g.3gpp.ti- 
value. Each octet of the figure 1 1 .9 of 3GPP TS 24.007 [75] is encoded by two hexadecimal digit, first of which 
represents the bits 8-5 of the octet. The transaction identifier flag is set as sent by the MSC server in CS signalling of 
the associated CS call. 

Table C.12A-1 : ABNF syntax of string values of the g.Sgpp.ti feature-capability indicator 

g.3gpp.ti-value = "<" HEXDIG HEXDIG *{ HEXDIG HEXDIG ) ">" 

Examples of typical use: Indicating capability of associating a CS call with dialog created by the SIP INVITE request. 

Security Considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [60]. 
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C.13 Definition of media feature tag g.3gpp.cs2ps-srvcc- 
alerting 

Media feature-tag name: g.3gpp.cs2ps-srvcc-alerting 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This media feature-tag when used in a Contact header field of a SIP 
request or a SIP response indicates that the functional entity sending the SIP message supports CS to PS SRVCC access 
transfer for calls in alerting phase. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a user equipment supports CS to PS SRVCC for calls in alerting phase. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

C.14 Definition of media feature tag g.3gpp.pstops-sti 

Media feature-tag name: g.3gpp.pstops-sti 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This media feature-tag when used in a Contact header field of a SIP 
request or a SIP response indicates that the functional entity sending the SIP message supports the use of the PS to PS 
STI URI. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that the user equipment supports the use of the PS to PS STI URI for access 
transfer. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 
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Annex D (informative): 
XIVIL schemas 

D.1 IVISC server assisted mid-call feature XML schema 
D.1.1 General 

This subclause defines XML schema and MIME type related to the MSC server assisted mid-call feature. 

D.1.2 XML schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs:element name="mid-call" type="Tmid-call"/> 

<xs : complexType name="Tmid-call" > 
<xs : sequence> 

<xs:element name= "participant" type="xs : anyURI" minOccurs="0" maxOccurs="unbounded"/> 
<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

</xs : schema> 

D.1 .3 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.mid-call+xml" as defined in this subclause is to be registered 
in the lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.mid-call+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 
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Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 

D.2 state-and-event-info XML schema 
D.2.1 General 

This subclause defines XML schema and MIME type for session state and event information. It is used in the present 
document for PS to CS SRVCC session transfer in alerting phase and for accepting of a call in alerting state transferred 
by the PS-PS access transfer procedures. 

D.2.2 XML schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 1/XMLSchema" 

elementFormDefault=" qualified" 

attributeFormDefault= "unqualified" > 

<xs : simpleType name="directionType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value=" initiator" /> 
<xs : enumeration value="receiver"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : element name=" state -and- event -info" type="Tstate-and-event-info"/> 

<xs : complexType name="Tstate-and-event-inf o" > 

<xs : sequence> 

<xs:element name="state-inf o" type="xs : string" minOccurs="0" maxOccurs="l"/> 

<xs:element name= "direction" type="directionType" minOccurs="0" maxOccurs="l"/> 

<xs:element name="event" type="xs : string" minOccurs="0" maxOccurs="l"/> 

<xs:element name= " anyExt " type="anyExtType" minOccurs="0" /> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name="anyExtType" > 
<xs : sequence> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
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</xs : complexType> 

</xs:schema> 

D.2.3 XML schema description 

This subclause describes the elements of the state-and-info XML Schema. 

<state-and-event-info>: The <state-and-event-info> element is used to indicate state and event information related 
to a specific dialog. In the present document, it is used to communicate information between the 
sec AS and the MSC-server for the purpose of PS to CS SRVCC in the alerting state and for UE 
to communicate acceptance of incoming alerting state call transferred using PS-PS access transfer 
procedures. 

<state-info>: The <state-info> element is used to indicate the state of the dialog and is modelled on the FSM 

described in IETF RFC 4235 [48]. In the present document, it can only have the values specified in 
table D.2.3- 1 for state-info- values. 

Table D.2.3-1 : ABNF syntax of values of the <state-info> element 

state-info-values = early-value 
early-value = %x65 . 61 . 72 . 6c . 79 ; "early" 

<direction>: The <direction> element indicates whether the observed user was the initiator of the dialog, or the 

recipient of the INVITE that created it. It can only have the values specified in table D.2.3-2 for 
direction-values. In the present document it must be included together with the <state-info> 
element. 

Table D.2.3-2: ABNF syntax of values of the <direction> element 

direction-values = initiator-value / receiver-value 
initiator-value = %x69 . 6e . 69 . 74 . 69 . 61 . 74 . 6f . 72 ; "initiator" 
receiver-value = %x72 . 65 . 63 . 65 . 69 . 76 . 65 . 72 ; "receiver" 

<event>: The <event> element is used to communicate an event that causes a dialog state transition. In the 

present document, the <event> element can only have the values specified in table D.2.3-3 for 
event-values. 

Table D.2.3-3: ABNF syntax of values of the <event> element 

event-values = call-accepted-value 

call-accepted-value = %x63 . 61 . 6c . 6c . 2d. 61 . 63 . 63 . 65 . 70 . 74 . 65 . 64 ; "call-accepted" 



D.2.4 lANA registration template 



Editor"s note: The MIME type "application/vnd.3gpp.state-and-event-infoH-xml" as defined in this subclause is to be 
registered in the lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.state-and-event-infoH-xml 

Required parameters: 

None 

Optional parameters: 
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"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 10.0.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 

D.3 SRVCC enhancement related XML schema 
D.3.1 General 

This subclause defines XML schema and MIME type for transfer of information for SRVCC enhancement. 

D.3.2 XML schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : complexType name=" SRVCC- infoType" > 
<xs : sequence> 

<xs:element name="ATU-STI" type="xs : anyURI" minOccurs="0"/> 

<xs:element name="C-MSISDN" type="xs : anyURI" minOccurs="0"/> 

<xs:element name="anyExt" type="anyExtType" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="ATCF-Path-URI" type =" xs : anyURI "/> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 
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<xs :complexType name="SRVCC-infosType" > 
<xs : sequence> 

<xs: element name="SRVCC-info" type="SRVCC-infoType" 

minOccurs= " 1 " maxOccurs= "unbounded" / > 
<xs: element name= " anyExt " type="anyExtType" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs:element name="SRVCC- infos" type="SRVCC-infosType"/> 

<xs : complexType name="anyExtType" > 

<xs : sequence> 

<xs : any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

<xs:element name="CS2PS-ATU-STI" type="xs : anyURI"/> 

</xs : schema> 



D.3.3 Semantic 



The <SRVCC-infos> element is the root element of the XML document and contains one or more <SRVCC-info> 
elements. 

Each <SRVCC-info> element contains SRVCC-related information related to one registration path (or registration flow, 
if multiple registration mechanism is used) of a UE with IM CN subsystem. The SRVCC-related information in the 
<SRVCC-info> element consists of: 

1) if the UE PS to CS SRVCC Capability (see 3GPP TS 29.328 [6]) has value UE-SRVCC-CAPABILITY- 
SUPPORTED and if the private user identity of the UE has associated STN-SR (see 3GPP TS 29.328 [6]): 

a) <ATU-STI> element containing the ATU-STI for PS to CS SRVCC of the SCC AS; and 

b) <C-MSISDN> element containing the Correlation MSISDN of the UE. 

NOTE 1: <ATU-STI> element and <C-MSISDN> element are not included if the UE PS to CS SRVCC CapabiHty 
(see 3GPP TS 29.328 [6]) has a value UE-SRVCC-CAP ABILITY-NOT-SUPPORTED or if the private 
user identity of the UE does not have an associated STN-SR (see 3GPP TS 29.328 [6]); and 

2) if CS to PS SRVCC is supported by SCC AS and enabled for the UE: 

a) <anyExt> element containing <CS2PS-ATU-STI> element containing the ATU-STI for CS to PS SRVCC of 
the SCC AS; and 

NOTE 2: The subelements of the <anyExt> are validated by the <xs:any namespace="##any" 

processContents="lax" minOccurs="0" maxOccurs="unbounded"/> particle of the <anyExt> element. 

b) <C-MSISDN> element containing the C-MSISDN of the UE. 

NOTE 3: If information for both CS to PS SRVCC and PS to CS SRVCC are included, <C-MSISDN> element is 
included only once. 

The "ATCF-Path-URI" attribute of the <SRVCC-info> element contains the ATCF URI for terminating calls of the 
registration path (or registration flow, if multiple registration mechanism is used). 

<anyExt> element contains optional elements defined by future version of this document. 

Recipient of the XML ignores any unknown element and any unknown attribute. 



D.3.4 lANA registration template 



Editor"s note [eSRVCC, CR#0417]: The MIME type "application/vnd.3gpp.SRVCC-infoH-xml" as defined in this 
subclause is to be registered in the lANA registry for Application Media Types based upon the following 
template. The registration is to be started when work on the SRVCC WID completes. 
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MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.SRVCC-info+xmI 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [2 1 ] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. Any unknown XML 
elements and any unknown XML attributes are to be ignored by recipient of the MIME body. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 10.2.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 

D.4 XML schema for CS to PS SRVCC information 
D.4.1 General 

This subclause defines XML schema and MIME type for transfer of CS to PS SRVCC information. 
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D.4.2 XML schema 

<?xml version="l . 0" ?> 
<xs : schema 

xmlns :xs = "http: //www.w3 . org/2 1/XMLSchema" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs:element name="srvcc-ext" type="srvcc-extType"/> 

<xs : complexType name="srvcc-extType" > 

<xs : sequence> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence > 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs: element name="PS-reg-info" type="PS-reg-infoType"/> 

<xs : complexType name="PS-reg-infoType" > 
<xs : sequence> 

<xs:element name="ATCF-Management-URI" type="xs : anyURI" minOccurs=" 0"/> 

<xs:element name="C-MSISDN" type="xs : anyURI" minOccurs=" 0"/> 

<xs:element name="cs2ps-srvcc-alerting" type="xs : boolean" minOccurs=" 0"/> 

<xs:element name="anyExt" type="anyExtType" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="Path" type="xs : anyURI" use="optional"/> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs:element name="Setup-inf o" type="Setup-inf oType"/> 

<xs : complexType name =" Setup -infoType" > 
<xs : sequence> 

<xs:element name="C-MSISDN" type="xs : anyURI"/> 
<xs:element name="direction" type="directionType"/> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs : simpleType name="directionType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value=" initiator" /> 
<xs : enumeration value="receiver"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="anyExtType" > 

<xs : sequence> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

</xs : schema> 

D.4.3 Semantic 
D.4.3.1 General 

The <srvcc-ext> element is the root element of the XML document. The <srvcc-ext> element can contain subelements. 

NOTE: The subelements of the <srvcc-ext> are validated by the <xs:any namespace="##any" 

processContents="lax" minOccurs="0" maxOccurs="unbounded"/> particle of the <srvcc-ext> element. 

When the <srvcc-ext> element contains the <PS-reg-info> element, then the <PS-reg-info> element contains: 

if the information relates to a registration of MSC server with IMS, then the "Path" attribute identifying the MSC 
URI for terminating calls used by MSC server when registering the UE; 
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optionally the <ATCF-Management-URI> element containing the ATCF management URI of the ATCF used in 
the registration path of the UE over a PS domain. Absence of this element indicates that the CS to PS SRVCC is 
disabled; 

- optionally the <C-MSISDN> element containing the C-MSISDN of the served SC UE. Absence of this element 
indicates that the CS to PS SRVCC is disabled; 

the <cs2ps-srvcc-alerting> element indicates whether the CS to PS SRVCC in alerting phase is supported by 
both the served SC UE and the SCC AS; and 

optionally, <anyExt> element containing elements defined by future version of this document. 

When the <srvcc-ext> element contains the <Setup-info> element, then the <Setup-info> element contains: 

- the <C-MSISDN> element containing the C-MSISDN of the served SC UE; 

the <direction> element indicating the role of the MSC server in the session set up. 
Recipient of the XML ignores any unknown element and any unknown attribute. 



D.4.4 lANA registration template 



Editor"s note [WID: rSRVCC-CT, CR 0624]: The MIME type "application/vnd.3gpp.srvcc-ext+xml" as defined in 
this subclause is to be registered in the lANA registry for Application Media Types based upon the 
following template. The registration is to be started when work on the rSRVCC-CT WID completes. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.srvcc-ext+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21]. 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations : 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. Any unknown XML 
elements and any unknown XML attributes are to be ignored by recipient of the MIME body. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 11.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 
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Intended usage: 
COMMON 
Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 



D.5 XML schema for access transfer events 



D.5.1 General 

This subclause defines XML schema and MIME type for transport of events related to access transfer of a session. 

D.5.2 XML schema 

<?xml version="l . 0" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault= "qualified" 

attributeFormDefault=" unqualified" > 

<xs:element name="events" type="eventsType"/> 

<xs : complexType name=" event sType" > 

<xs : sequence> 

<xs:element name="event" type="eventType" maxOccurs="unbounded"/> 

</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs : complexType name="eventType" > 

<xs : sequence> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence> 

<xs : attribute name=" event -type" type="xs :unsignedInt"/> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs: element name="STNResp-params" type="STNResp-paramsType"/> 

<xs : complexType name="STNResp-paramsType" > 
<xs : sequence> 

<xs:element name="transf er-details" type="xs :base64Binary"/> 
<xs:element name="redirect-speech" type="xs : boolean" /> 

<xs : any namespace="##any" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

</xs : schema> 

D.5. 3 Semantic 
D.5.3.1 General 

The <events> element is the root element of the XML document and contains one or more <event> elements. 
Each <event> element describes one event occuring in session and: 
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1) contains the "event-type" attribute which indicates the event type; and 

2) can contain subelements related to the event type indicated by the "event-type" attribute. 

NOTE: The subelements of the <event> are validated by the <xs:any namespace="##any" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> particle of the <event> element. 

The following applies for the "event-type" attribute of the <event> element: 

sender of the XML does not set the "event-type" attribute to any value other than those described in this section; 
and 

recipient of the XML ignores the <event> element with "event-type" attribute containing a value other than those 
described in this section. 

Recipient of the XML ignores any unknown element and any unknown attribute. 

D.5.3.2 Requirements for individual events 

If the "event-type" attribute of the <event> element is 1, then the <event> element indicates the session transfer 
notification request. 

If the "event-type" attribute of the <event> element is 2, then the <event> element indicates the session transfer 
notification response and the <event> element contains the <STNResp-params> element and the <ATGW-anchored> 
element. The <STNResp-params> element contains <transfer-details> element containing the content according to 
subclause D.5.3.3. The <redirect-speech> element indicates whether the ATCF requires the MSC server to redirect the 
speech media component of the session transferred by the CS to PS SRVCC access transfer. 

NOTE 1 : Binary data are encoded according to the XML type base64Binary. 

NOTE 2: MIME body with the "event-type" attribute of the <event> element equal to 2 is provided after receiving 
the MIME body with the "event-type" attribute of the <event> element equal to 1. 

If the "event-type" attribute of the <event> element is 3, then the <event> element indicates the session transfer 
preparation. 

NOTE 3: MIME body with the "event-type" attribute of the <event> element equal to 3 is provided after receiving 
the MIME body with the "event-type" attribute of the <event> element equal to 2. 

If the "event-type" attribute of the <event> element is 4, then the <event> element indicates the session transfer 
cancellation. 

NOTE 4: MIME body with the "event-type" attribute of the <event> element equal to 4 is provided either after 
receiving the MIME body with the "event-type" attribute of the <event> element equal to 2 or after 
providing the MIME body with the "event- type" attribute of the <event> element equal to 3. 



D.5.3.3 



ATGW transfer details 



The ATGW transfer details indicate the ATGW media configuration to be used by SC UE when sending the speech 
media of the session transferred by the CS to PS SRVCC access transfer. 

The ATGW transfer details are encoded in the structure shown in the figure D. 5. 3. 3-1 and table D. 5. 3. 3-1. 
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Figure D.5.3.3-1 : ATGW transfer details structure 
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Table D.5.3.3-1 : ATGW transfer details structure 



In this version of specification, the sender sets the Reserved i\e\6 to zero and the 
recipient ignores the ffeservec/ field. 

The ATGW transfer details content type field indicates type of the ATGW transfer 
details content. Bit 2 of the ATGW transfer details content type field contains the 
most significant bit. 

In this version of the specification, the following ATGW transfer details content type 
values are specified: 

- (ATGW-IPv4-address-and-port); 

- 1 (ATGW-IPv6-address-and-port). 

- 2 (ATGW-not-available). 

When the ATGW transfer details content type field indicates value other than those 
specified in this version of the specification, the ATGW Transfer details content f\e\6 
is ignored by the recipient. The sender sets the ATGW transfer details content type 
field only to a value specified in this version of the specification. 
When the ATGW transfer details content type field indicates ATGW-IPv4-address- 
and-port, the ATGW Transfer details confenf field is structured as in Figure D.x.3.3- 

2 and Table D.x.3.3-2. 

When the ATGW transfer details content type field indicates ATGW-IPv6-address- 
and-port, the ATGW Transfer details content f\e\6 is structured as in Figure D.x.3.3- 

3 and Table D.x.3.3-3. 

When the ATGW transfer details content type field indicates ATGW-not-available, 
the ATGW Transfer details confenf field is not included. 
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Figure D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content 

type field indicates ATGW-IPv4-address-and-port 

Table D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content 

type field indicates ATGW-IPv4-address-and-port 



The ATGW UDP port f\e\d indicates the ATGW UDP port to be used by SC UE to 
send the speech media of the session transferred by the CS to PS SRVCC access 
transfer. Bit 8 of the first octet of the ATGW UDP port f\e\6 contains the most 
significant bit and bit 1 of the second octet of the ATGW UDP port field contains the 
least significant bit. 

The ATGW IPv4 address field indicates the ATGW IPv4 address to be used by SO 
UE to send the speech media of the session transferred by the OS to PS SRVCC 
access transfer. Bit 8 of the first octet of the ATGW IPv4 address field contains the 
most significant bit and bit 1 of the fourth octet of the ATGW IPv4 address field 
contains the least significant bit. 

In this version of specification, the sender does not include the extensions field and 
the recipient ignores the extensions field. 
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Figure D.5.3.3-3: ATGW transfer details content structure whien the ATGW transfer details content 

type field indicates ATGW-IPv6-address-and-port 



Table D.5.3.3-3: ATGW transfer details content structure when the ATGW transfer details content 

type field indicates ATGW-IPv6-address-and-port 



The ATG\N UDP port f\e\d indicates tlie ATGW UDP port to be used by SO UE to 
send tlie speecli media of the session transferred by the OS to PS SRVGG access 
transfer. Bit 8 of the first octet of the ATGW L/DP port field contains the most 
significant bit and bit 1 of the second octet of the ATGW UDP port i\e\6 contains the 
least significant bit. 

The ATGW IPv6 address field indicates the ATGW IPv6 address to be used by SC 
UE to send the speech media of the session transferred by the CS to PS SRVCC 
access transfer. Bit 8 of the first octet of the ATGW IPv6 address field contains the 
most significant bit and bit 1 of the sixteenth octet of the ATGW IPv6 address field 
contains the least significant bit. 

In this version of specification, the sender does not include the extensions field and 
the recipient ignores the extensions field. 



D.5.4 lANA registration template 



Editor"s note [WID: rSRVCC-CT, CR 0625]: The MIME type "application/vnd.3gpp.access-transfer-events+xml" 
as defined in this subclause is to be registered in the lANA registry for AppHcation Media Types based 
upon the following template. The registration is to be started when work on the rSRVCC-CT WID 
completes. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.access-transfer-events+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

"et" when the MIME type is included in the Accept header field, the "et" parameter value is a comma delimited list of 
the values of the "event-type" attribute of the <event> element of the <events> root element which the sender of the 
Accept header field is able to receive. The <events> root element is defined by XML schema described in the Published 
specification. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21]. 
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Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. Any unknown XML 
elements and any unknown XML attributes are to be ignored by recipient of the MIME body. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 11.2.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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Annex E (informative): 

INFO packages defined in the current document 

E.1 Info package for transfer of the conference 
information 

E.1.1 Scope 

This subclause contains the information required for the lANA registration of info package g.3gpp. mid-call in 
accordance with IETF RFC 6086 [54]. 

Editor"s note: MCC needs to register this info package with lANA when 24.237 9.6.0 is published. 

E.1 .2 g.Sgpp. mid-call info package 
E. 1 .2. 1 Overall description 

When PS to CS access transfer with the MSC Server assisted mid-call feature is applied for a session with conference 
focus there is a need to deliver participant identities from SCC AS to MSC server. 

E.1. 2.2 Applicability 

This package is used to transport participant identities when the PS to CS access transfer with the MSC server assisted 
mid-call feature is applied to a session with conference focus. 

E.1 .2.3 Info package name 

g.3gpp. mid-call 

E.1 .2.4 Info package parameters 

None defined 

E.1. 2.5 SIP options tags 

None defined 

E.1 .2.6 INFO message body parts 

The MIME type of the message body carrying participant identities is application/vnd.3gpp.mid-callH-xml. 
apphcation/vnd.3gpp.mid-callH-xml MIME type is defined in 3GPP TS 24.237. 

When associated with the g.3gpp.mid-call info package, the Content-Disposition value of the message body carrying 
participant identities is "info-package". 

E.1 .2.7 Info package usage restrictions 

None defined. 



ETSI 



3GPP TS 24.237 version 1 1 .6.0 Release 1 1 360 ETSI TS 1 24 237 V1 1 .6.0 (201 3-04) 

E.1 .2.8 Rate of INFO Requests 

Single INFO request generated after session set up. 

E.1 .2.9 Info package security considerations 

The security is based on the generic security mechanism provided for the underlying SIP signalhng. No additional 
security mechanism is defined. 

E.1. 2. 10 Implementation details and examples 

UAC generation of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 

Stage 3" 

UAS processing of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 

Stage 3" 

Examples: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 



E.2 INFO package for transfer of state-and-event info 



E.2.1 Scope 

This annex defines an info package in accordance with IETF RFC 6086 [54] for sending state and event information 
during PS to CS SRVCC access transfer using SIP INFO requests. 

E.2. 2 state-and-event info package 
E. 2.2.1 General 

This subclause contains the information required for the lANA registration of an info package. 
Editor"s note: MCC needs to register this info package with lANA after Rel-10 has been frozen. 

E.2. 2. 2 Overall description 

When PS to CS SRVCC access transfer from PS to CS access is applied for a session with an active full duplex speech 
component and the related dialog is in early state there is a need to deliver state information from an SCC AS to an 
MSC server. Further it is requested that an MSC server supporting SRVCC access transfer for in alerting phase informs 
the SCC AS about a UE having accepted a terminating call. 



E. 2.2.3 Applicability 

This package is used to transport session state information and related event information when a session in alerting 
phase is transferred from PS to CS using SRVCC access transfer procedures. 

The mechanism allows that information about the session that is subject to PS to CS SRVCC and related events to be 
sent inside an existing dialog due to the session transfer SIP INVITE request. 

E.2. 2. 4 Info package name 

The name of the info package is g.3gpp. state-and-event. 
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E.2.2.5 Info package parameters 

No parameters are defined for the g.3gpp.state-and-event info package. 

E. 2.2.6 SIP option tags 

No SIP option tags are defined for the g.3gpp.state-and-event info package. 

E.2.2.7 INFO message body parts 
E. 2.2. 7.1 General 

The state-and-event information is carried in the state-and-event-info message body, defined in annex D of 
3GPP TS 24.237. 

E.2.2.7.2MIMEtype 

The MIME type value for the message body is "application/vnd.3gpp.state-and-event-info+xml", defined in annex D of 
3GPP TS 24.237. 

E.2.2.7. 3 Content disposition 

The Content Disposition value for the message body, when associated with the g.3gpp. state-and-event info package, is 
"info-package" as defined in IETF RFC 6086 [54]. 

E.2.2.8 Info package usage restrictions 

No usage restrictions are defined for the g.3gpp.state-and-event info package. 

E. 2.2.9 Rate of INFO requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the g.3gpp. state-and-event 
info package. 

When PS to CS SRVCC in alerting phase is applied, then a single SIP INFO request is generated after the session 
transfer SIP INVITE request. This can be followed by one more additional SIP INFO request. 

E.2.2.10 Info package security considerations 

No additional security mechanism is defined for the g.3gpp. state-and-event info package. 

The security of the g.3gpp. state-and-event info package is based on the generic security mechanism provided for the 
underlaying SIP signalling. 

E.2.2.1 1 Implementation details and examples 

See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 



E.3 INFO package for transfer of access transfer events 



E.3.1 Scope 



This annex contains the information required for the lANA registration of info package g.3gpp. access-transfer-events in 
accordance with IETF RFC 6086 [54]. 
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Editor"s note: [WID: rSRVCC-CT, CR 0626] MCC needs to register this info package with lANA when work on 
rSRVCC-CT completes. 

E.3.2 g.Sgpp. access-transfer-events info package 
E.3.2.1 Overall description 

This info packages enables SIP entities to inform each other about events occuring during access transfer of session 
between access networks. E.g. during CS to PS single radio voice call continuity access transfer the MSC server needs 
to inform ATCF about the session transfer notification request, ATCF needs to inform MSC server about the session 
transfer notification response and MSC server needs to inform ATCF about the session transfer preparation. 

E. 3.2.2 Applicability 

The info package mechanism has been selected since the transported information cannot be sent in media plane as 
entities receiving the information are not mandated to always anchor the media and since usage of subscription in order 
to transport the information has not been seen as feasible as the information can be exchanged bidirectionally. 

E.3.2. 3 Info package name 

g.3gpp.access-transfer-events 

E.3.2. 4 Info package parameters 

"et" when included in the Recv-Info header field and when Accept header field is not present in the SIP message, the 
"et" parameter value is a comma delimited list of the values of the "event-type" attribute of the <event> element of the 
<events> root element which the sender of the Recv-Info header field is able to receive. The <events> root element is 
defined in XML schema of the MIME type application/vnd.3gpp.access-transfer-events+xml. This parameter applies for 
the Recv-Info header field and does not apply for the Info-Package header field. 

E. 3.2.5 SIP option tags 

None defined 

E.3.2. 6 INFO message body parts 

The MIME type of the message body carrying events information is application/vnd.3gpp.access-transfer-eventsH-xml. 
The application/vnd.3gpp.access-transfer-eventsH-xml MIME type is defined in 3GPP TS 24.237. 

When associated with the g.3gpp. access-transfer-events info package, the Content-Disposition value of the message 
body carrying participant identities is "info-package". 

E.3.2. 7 Info package usage restrictions 

None defined. 

E. 3.2.8 Rate of INFO requests 

The rate of the INFO requests depends on the supported event types. 

E.3.2. 9 Info package security considerations 

The security is based on the generic security mechanism provided for the underlying SIP signalling. No additional 
security mechanism is defined. 
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E.3.2.10 Implementation details and examples 

UAC generation of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 

Stage 3" 

UAS processing of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 

Stage 3" 

Examples: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 
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8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0094 


2 


MSC Server assisted mid-call feature - SRVCC 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0106 


2 


E-SCC AS actions for IMS Emergency call 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0109 


1 


MSC Server assisted mid-call feature - PS to CS 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0111 


3 


MSC Server assisted mid-call feature - PS to PS 


8.3.0 


9.0.0 


2009-12 


CT#46 


CP-090929 


0048 


2 


Call flow for Remote party releases Collaborative Session 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0096 


3 


Signalling flow for Controller UE releases media flow on 
controller UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0097 


3 


Signalling flow for Controller UE releases media on Controllee 
UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0099 


3 


Signalling flow for Controllee UE modify media on itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0100 


6 


Signalling flow for Remote party adds new media on controllee 
UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0101 


3 


Signalling flow for Remote UE releases media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0110 


3 


MSC Server assisted mid-call feature - CS to PS - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0116 


4 


Roles for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0117 


5 


Roles of SCC AS for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0122 


1 


MSC Server assisted mid-call feature - flow updates - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0124 


1 


MSC Server assisted mid-call feature - capability exchange 
update 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0125 


1 


MSC Server assisted mid-call feature - PS to CS and SRVCC 


9.0.0 


9.1.0 
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updates - Atll 






2009-12 


CT#46 


CP-090929 


0128 


1 


MSC Server assisted mid-call feature - PS to PS updates 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0131 




sec UE not defined 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0132 




Renaming of E-SCC AS to EATF 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0133 


2 


E-SRVCC session origination 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0134 


2 


E-SRVCC access transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0136 


2 


Call flow for transferring a media to a controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090928 


0146 


1 


Correction on PS-CS transfer information flow 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0149 


1 


MSC Server assisted mid-call feature - transaction identifiers 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090911 


0153 


1 


Enabling session continuity functionality 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0155 


2 


SC UE procedures for collaborative session establishment for 
transferring media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0156 


2 


SC UE procedures for collaborative session establishment with 
new media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0157 


2 


sec AS procedures for collaborative session establishment for 
transferring media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090911 


0160 


1 


Address the Editor's Note in A. 3. 2 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090911 


0162 


1 


Address the Editor's Note in A. 8. 2 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0164 


2 


PS to CS transfer for speech and video session with MSC 
Server asisted mid-call feature 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0170 


2 


lUT Procedures 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0171 


2 


Call flow for adding media to controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-091047 


0173 


3 


SC AS procedures for collaborative session establishment with 
new media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0174 


3 


Procedures for releasing media on controllee UE by controller 
UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0175 


3 


Procedure for adding new media by remote party 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0176 


3 


Procedure for releasing media on ontroller UE by controller UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0177 


3 


Procedure for modifying media on contrllee UE by itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0178 


2 


Signalling flow for Controllee UE releases media 


9.0.0 


9.1.0 


2010-03 


CT#47 


CP-100123 


0144 


5 


PS to CS or to (PS-i-CS) session transfer for an SC UE using Gm 
interface 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0182 


1 


Procedures for collaborative session release by controller UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0183 


1 


Procedures for controllee UE releases media component 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0184 


1 


Procedures for collaborative session release by remote party 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0185 


1 


Procedures for controller UE initiated media transfer from 
controller UE to controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0186 


1 


Establishment of collaborative session for inter-UE transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0187 


1 


Media adding/deleting within collaborative session for inter-UE 
transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0188 


2 


Procedures for releasing media by remote UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100199 


0189 


4 


Controller UE initiated media transfer from controllee UE to 
another controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0191 


2 


Procedures for controller UE initiated media transfer from 
controllee UE to another controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0192 


3 


Procedures for controller UE initiated media transfer from 
controllee UE to another controllee UE— SCC AS behavior 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0193 




Signalling flows for media transfer within collaborative session 
for inter-UE transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0194 




Access tranfer and MMTEL interaction 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0195 


2 


Inter-UE transfer and MMTEL interaction 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0196 




Procedures for adding new media on controllee UE by controller 
UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0198 




Release of collaborative session for inter-UE transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0199 


2 


Procedures for controllee UE releases media component 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0200 




Procedures for collaborative session release by remote party 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0201 




Procedures for controller UE initiated media transfer from 
controller UE to controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0202 


3 


Adding new media on controllee UE by controller UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0203 


3 


procedures for subscription to the session description 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0204 




SR VCC from MSC 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0206 




Deleting the editor note at A.I 5.3.2.2 for controller UE removing 
media at controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0207 




Deleting editofs note for clause A. 15. 3.1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0208 




Deleting the editor note at A.15.5 for controllee UE modify meida 
on itesif 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0209 


2 


Complete session transfer routing clarification 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0210 




MSC Server assisted mid-call feature - single held session 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0211 




MSC Server assisted mid-call feature - flow clean up 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0212 


2 


MSC server assisted mid-call feature - sendonly, recvonly 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0213 




Incorrect reference correction 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0214 




Removal of ICMP message sending - procedures 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0217 




Registration requirements for an SC UE that only implements 


9.1.0 


9.2.0 
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Inter-UE Transfer 






2010-03 


CT#47 


CP-100142 


0218 


2 


Addition of the Content-Type to SIPfrag containing SDP 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0219 


3 


Separating releasing media on controllee UE and removing 
controllee UE from collaborative session 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0220 




Correction of Procedures for adding new media by remote party 
when the controller UE does not alert the user 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0221 




Removal of Editor's Note on use of SDP in URI parameters in 
Refer-To header 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0223 




Editorial changes to clause 8 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0224 




Editorial changes to clause 9 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0225 




Editorial changes to clause 14 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0226 




Editorial changes to clause 16 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0227 




Editorial changes to clause 19 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0228 




Editorial changes to clause A. 12.3 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0229 




Editorial changes to clause A. 13.2 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0230 




Editorial changes to clause A. 14 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0232 




Editorial changes to clause A. 16 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0233 




Editorial changes to clause C.2 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100123 


0236 


3 


Clarification of SC OMA MO use 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 00240 


0237 




Removal of IMS communication service from emergency call 
flows 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100135 


0238 




SR VCC abnormal case 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100123 


0240 




Correct the definition of Correlation MSISDN 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0241 


2 


Controller UE initiated media transfer from controllee UE to 
another controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0242 




UE remote changed to Remote UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0243 


1 


Merged corrections to A.15.3.2.1 , A.I 5.3.2.2 agreed at the 
CTIe-meeting 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 001 40 


0244 




EATF editor's notes resolution 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0245 




EN on SIP URI of sec AS 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0246 


2 


Collaborative session establishement of with new media 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0247 


1 


sec AS procedures for collaborative session establishment with 
new media 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0248 


4 


Addition of media feature tag for indicating lUT Controller 
capability 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0249 




Editorial changes to clause 4 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0250 




Editorial changes to clause 6 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0251 




Editorial changes to clause 7 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0252 


2 


Editorial changes to clause 10 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0253 


1 


Editorial changes to clause 1 1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0254 




Editorial changes to clause 12 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0255 




Editorial changes to clause 13 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0256 




Editorial changes to clause A. 3 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0257 




Editorial changes to clause A. 6 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0258 




Editorial changes to clause A. 7 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0259 




Editorial changes to clause A. 8 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0260 




Editorial changes to clause A. 9 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0261 




Editorial changes to clause A.1 1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0262 




Editorial changes to clause A. 16 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 001 40 


0263 




Editorial changes to clause A. 17 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0264 




Inappropriate normative language in relation to registration 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0197 




Remove of signaling flow for target UE discovery 


9.1.0 


9.2.0 


2010-03 


CT#47 








Editorial cleanup by MCC 


9.1.0 


9.2.0 


2010-06 


CT#48 


CP-1 00359 


0130 




MSC Server assisted mid-call feature - conferencing 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0265 


2 


Removal of editorial notes 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0266 




Controllee UE announces controller capabilities 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0268 




Editorial corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0275 




Correction of references 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0276 




Removing controllee UE procedure correction 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0279 




Compliance corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0280 




PS-CS access transfer corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0282 




PS to CS-i-PS access transfer corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0283 


2 


SRVCC corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0284 




Race condition during SRVCC 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0285 


2 


MSC Server assisted mid-call feature and SR VCC abnormal 
case 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0286 




Inter UE Transfer corrections - procedure overlap 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0287 


2 


Inter UE Transfer corrections - collaborative session by media 
transfer 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0288 


2 


Inter UE Transfer corrections - collaborative session by media 
transfer 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0289 




Inter UE Transfer corrections - session discovery corrections 


9.2.0 


9.3.0 
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2010-06 


CT#48 


CP-1 00359 


0290 


1 


Inter UE Transfer corrections - media transfer during col. session 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0291 


1 


Inter UE Transfer corrections - media adding/deleting during col. 
session 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0292 


2 


Correction of Referred-By header usage 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0293 


1 


Correction of iut-controller feature tag usage 


9.2.0 


9.3.0 


2010-09 


CT#49 


CP-1 00505 


0298 




Editorial Corrections 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0299 




Removing unnecessary condition for sending SIP UPDATE or 
SIP re-INVITE request 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0307 


2 


Clarifying SC UE procedures for terminations 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0308 


1 


Inform remote end about new local end 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0310 


3 


Corrections use of 3GPP TS 24.216 MO leaf 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0314 


3 


Modification of SCC AS procedure in MSC server assisted mid- 
call feature 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0315 


2 


lUT Cleanup 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0319 


1 


UE compliance 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0327 


1 


Modification thie usage for instance ID in session transfer 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0328 


2 


Clarification of MSC server apply ICS capability 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-100519 


0316 


1 


Insertion of missing requirement to prohiibit PS-CS continuity 


9.4.0 


10.0.0 


2010-09 


CT#49 


CP-100519 


0321 


1 


Error correction and modify signalling flows for controller UE 
initiated media transfer from controller UE to controllee UE 


9.4.0 


10.0.0 


2010-09 


CT#49 


CP-100519 


0322 


1 


Add signalling flows for collaborative session establishment with 
media transfer 


9.4.0 


10.0.0 


2010-12 


CT#50 


CP-1 00863 


0304 


6 


Flow for SRVCC in alerting state - terminating case 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0305 


6 


Flow for SRVCC in alerting state - originating case 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0311 


9 


Mid-call scenairos for incoming and outgoing call in alerting state 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0325 


5 


Call flow for transfering an incoming waiting call in alerting phase 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0338 


3 


Signalling flows for PS-CS access transfer when using ATCF 
enhancements and without media anchored 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0339 


5 


Signalling flows for PS-CS access transfer when using ATCF 
enhancements and media anchored 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00842 


0342 


2 


Corrections of SC UE registaration 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00737 


0345 


1 


ICS UE prevented from Gm control adding when ICS is disabled 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0350 


4 


SRVCC enhancements - registration flow 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0351 


3 


SRVCC enhancements - originating session set up flow 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0353 


3 


SRVCC enhancements - ATCF registration procedures 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0354 


1 


SRVCC enhancements - scope, definition, compliance 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00842 


0359 




Correction in SRVCC Emergency Flows. 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0360 


3 


Flows for SRVCC in alerting state - Race condition when 
answering in PS 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0362 


2 


SCC AS procedures for SRVCC alerting state 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0364 


3 


MSC server procedure for SRVCC in alerting 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0365 


3 


Definition of INFO package for SRVCC alerting 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0367 


2 


Further flow for SRVCC in alerting state race condition when 
answering in PS 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0368 


2 


UE and SCC AS procedures for abnormal cases of SRVCC 
when in Alerting Phase 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00863 


0369 


2 


SC UE procedures for SRVCC in Alerting Phase 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0372 


3 


SCC AS procedure for PS to CS Access Transfer: SRVCC 
enhancements using ATCF 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00737 


0375 


2 


Correction of the SCC AS association procedure 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00843 


0352 


2 


SRVCC enhancements - ATCF invocation 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00746 


0335 


1 


Editors note deleting for remote UE releases media on the 
controller UE 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00746 


0356 


1 


SRVCC clarifications for SDP offer by the MSC. 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00864 


0361 


5 


PS-PS access transfer in early dialog state 


10.0.0 


10.1.0 


2011-03 


CT#51 


CP-1 101 96 


0377 


2 


Remote leg release 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 96 


0379 


2 


Previously established dialog. 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 96 


0381 


1 


Contact registration 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 99 


0382 


1 


Editor's note delete for aSRVCC on A. 17.1 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 98 


0383 


2 


Adding clauce A.I 8 for eSRVCC signalling flow 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 78 


0393 




Reference update: RFC 6086 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 99 


0394 


1 


STN-SR missing in procedures 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 99 


0395 


2 


Tl assignment for MSC server for srvcc for alerting call 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 96 


0409 




g.3gpp. access-type media feature tag name corrected 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 78 


0411 




g.3gpp. mid-call info package description corrected 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 96 


0412 




PS-PS access transfer, accepting terminating early dialog 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 99 


0413 


3 


Alerting SRVCC when another call exists 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 98 


0414 


2 


SRVCC enhancement, ATCF access transfer procedures 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 98 


0415 


2 


SRVCC enhancement, ATCF compliance update 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 98 


0417 


5 


Format and triggers for SCC AS sending ATU-STI and C- 
MSISDN to ATCF 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 98 


0418 


5 


SRVCC enhancement, ATCF call set up procedures 


10.1.0 


10.2.0 
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2011-03 


CT#51 


CP-110199 


0422 




Allowing state-and-event-info XML to be used for other 
applications in future 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110199 


0423 


4 


Corrections of UE procedures for SRVCC in alerting state 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110178 


0426 


3 


Clarification of MSC server procedures. 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110196 


0429 


1 


PS-PS transfer corrections 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110169 


0432 


2 


Active media component 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110198 


0433 


3 


Transport of ATU-STI and C-MSISDN from SCC AS to ATCF 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110198 


0434 


1 


SRVCC enhancement, ATCF procedures when no active call 
exists 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110198 


0435 


2 


SRVCC enhancements, SCC AS procedure 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110199 


0436 


2 


Indicating support for SRVCC alerting state 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110198 


0453 




Referencing 3GPP TS 23.003 for identity definitions 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110199 


0455 


1 


Adding call flow for incoming call in alerting phase with forked 
responses 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110199 


0456 


1 


Adding the SCC AS procedure for originating call in alerting 
phase when forked responses received 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10290 


0440 


3 


Shifting Rel-9 lUT material OUT of TS 24.237 


10.1.0 


10.2.0 


2011-06 


CT#52 


CP-1 10449 


0398 


3 


Transferable Sessions 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0459 




Reference update: draft-ietf-sipcore-proxy-feature 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0460 




Correcting erroneous references 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0461 




Correcting erroneous subclause references 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0462 


1 


SC UE checking dialog parameters 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0463 




Functional entities missing in some introductions 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10470 


0465 


1 


g.3gpp. mid-call media feature in 2xx response 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0466 


1 


ATCF adding Record-Route 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0467 


2 


EN on ATCF URI assignment 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0468 




SRVCC related information received when session{s) exist 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10465 


0469 


1 


PS-PS access transfer corrections 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0470 


2 


SRVCC transferable session 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10470 


0471 


1 


ENs in alerting SRVCC 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10470 


0472 




Add description of SRVCC alerting with forked responses to 
introduction clause 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10470 


0473 


2 


Missing aspects for SRVCC due to different permutations of UE 
and network support 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10449 


0476 


2 


Speech component in session 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10470 


0477 


1 


Handling of error in INFO request 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0479 


1 


Editor's notes clean up for eSRVCC 


10.2.0 


10.3.0 


2011-06 


CT#52 


CP-1 10469 


0482 


2 


Determining eSRVCC transferable session set 


10.2.0 


10.3.0 


2011-09 


CT#53 


CP-1 10681 


0483 




Redundant text removal 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10681 


0488 


3 


P-CSCF releasing dialog during PS-to-PS access transfer 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10681 


0489 


2 


P-CSCF releasing the early dialog during PS-to-PS transfer 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0490 


2 


ATCF retaining session state information during SRVCC 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10681 


0491 


2 


P-CSCF releasing the early dialog during SR-VCC 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10681 


0492 




Transferable Session - fixing of incorrect CR 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0493 


4 


SRVCC related information 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0496 


1 


Removing confusing "old IP-CAN" 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10670 


0497 


1 


Clarifying the Inter UE Transfer SCC AS URI 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10685 


0498 


1 


Misleading reference in PS to CS transfer incoming call waiting 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10685 


0501 




SRVCC transferable session not defined 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10681 


0502 


1 


SRVCC and session with full-duplex speech media component 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10655 


0505 




SRVCC transfers speech media component of established 
session 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10672 


0507 


1 


Assignment of transferred sessions to CS calls 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0508 


2 


Cleanup of ATCF procedures 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10685 


0509 


1 


Alerting session may not be transferred when UE has Active + 
Alerting + Held call 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0510 


2 


Update of a note in 6.3.1 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0511 




Modifying references of ATCF functionality 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0512 


1 


Correction on ATCF behavior when receiving a SIP INVITE 
request 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0514 


2 


MSC contact address 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10674 


0515 


2 


Contact at ATCF 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10655 


0529 


1 


SCC AS procedures in SRVCC 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10672 


0534 


1 


Correcting terminology and references used in subclause 12.3 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10685 


0535 


1 


Missing reference to the PS to CS access transfer for alerting 
calls 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10685 


0536 


2 


Release of source access leg when signalling path is 
unavailable between UE and SCC AS 


10.3.0 


10.4.0 


2011-09 


CT#53 


CP-1 10693 


0484 


2 


Flow for PS-PS Transfer for outgoing call in alerting phase 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0485 


2 


Flow for PS-PS Transfer for incoming call in alerting phase 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0495 


1 


Forking to both CS and PS contact 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0513 


2 


ATGW performing transcoding 


10.4.0 


11.0.0 
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2011-09 


CT#53 


CP-1 10693 


0516 


2 


Media path switching at ATGW 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0518 


2 


ATCF-Note removal 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0519 


1 


PS to PS transfer at the SC UE 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10693 


0520 


2 


PS to PS transfer at the SCC AS 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10697 


0523 


2 


General IIVIS procedures for vSRVCC 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10697 


0524 


2 


SC UE procedures for vSRVCC 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10697 


0525 


2 


IVISC Server procedures for vSRVCC 


10.4.0 


11.0.0 


2011-09 


CT#53 


CP-1 10697 


0526 


2 


SCC AS procedures for vSRVCC 


10.4.0 


11.0.0 


2011-12 


CT#54 


CP-1 10881 


0545 




IVIedia feature tag removed 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0546 


1 


ATCF selection 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0548 


3 


Resource-Priority handling in ATCF 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0549 


1 


eMPS for SRVCC 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10865 


0552 


1 


Transfer failure if configuration tables are changed after the 
session was established 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0553 


1 


SRVCC PS to CS transfer of alerting call - FLOW 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0554 


1 


g.3gpp.srvcc-alerting media feature tag missing in flows 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10879 


0562 


3 


Reference to Contact changed to reference Feature-Caps 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0563 


1 


Reference to PS to CS access transfer for alerting in MSC 
server 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0564 


2 


Single call and call state association missing in MSC server 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0565 


2 


Readability correction 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0568 


2 


Action in MSC server when receiving 200 OK is missing 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10879 


0570 




Answer shall be call-accepted 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0571 


1 


CS Connect shall be CC CONNECT 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0573 




Incorrect reference to 24.229 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0576 


3 


Serving network capabilities 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0578 


1 


Media offered by ATCF in target access leg during SRVCC 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0580 


1 


ATCF procedures and "loose route" indication 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10867 


0586 


1 


Missing SRVCC for IMS emergency procedures for MSC server 
enhanced for ICS 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10884 


0587 




Removal of Editor's Note on use of SIP OPTIONS and fixing 
editorials 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0591 


1 


Correction of charging headers 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0594 


2 


Cleanup of ATCF procedures 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0595 


1 


Flow correction for SRVCC enhancements 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0596 




SCC AS includes option tags 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10873 


0598 


1 


Record-Route at ATCF 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0599 


2 


ATCF on the signalling path 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10873 


0602 




Removing the Accept header field from 183 response 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10878 


0604 


3 


proxy-feature l-D reference update 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10882 


0606 


2 


PS to CS SRVCC update 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0609 




Incompatible codec when transfering a call using ATCF 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10881 


0612 




Replacing reused procedures for SRVCC and vSRVCC in SCC 
AS 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10884 


0613 


1 


vSRVCC video bearer identification not required 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10884 


0614 


2 


Determination of vSRVCC handover 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10884 


0616 


2 


Corrections to SC UE procedures for vSRVCC 


11.0.0 


11.1.0 


2011-12 


CT#54 


CP-1 10884 


0617 


1 


Example signalling flow for vSRVCC 


11.0.0 


11.1.0 


2012-03 


CT#55 


CP-120120 


0619 




CS to PS SRVCC, registration flows in PS 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0620 




CS to PS SRVCC, registration flows in CS 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0621 




CS to PS SRVCC, originating call 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0622 




CS to PS SRVCC, terminating call 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0624 




CS to PS SRVCC, MIME type for CS to PS SRVCC information 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0625 


1 


CS to PS SRVCC, MIME type to be used with INFO 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0626 




CS to PS SRVCC, INFO package 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0627 




CS to PS SRVCC, feature tags 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120107 


0630 


1 


ATCF passing Recv-lnfo, Supported, Accept 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120124 


0631 


1 


MSC server assisted mid-call feature - merging MSC server 
SRVCC procedures 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-1 20095 


0634 




Speech media component 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120107 


0638 


1 


ATCF-Path-URI in MESSAGE sent from SCC AS 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120107 


0640 


2 


REGISTER handling in ATCF 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120106 


0642 


1 


Overlapping conditions in MSC on INFO 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120124 


0643 


2 


Adding ICS control during SRVCC 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120124 


0644 


1 


SRVCC Charging correlation 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120107 


0646 


1 


Reference update: draft-holmberg-sipcore-proxy-feature 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120126 


0647 


2 


Unclear MSC specification of alerting functionality for vSRVCC 
and SRVCC. 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120124 


0648 




Incorrect reference to use of operator specific timer for source 
access release. 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0649 




Signalling flows for eSRVCC assisted mid-call feature including 
ATCF 


11.1.0 


11.2.0 
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2012-03 


CT#55 


CP-120124 


0651 


1 


Clarifying SCC AS behavior when removing media during full 
PS-PS access transfer 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0652 




CS to PS SRVCC, keys to flows 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0654 




CS to PS SRVCC, ATGW transfer details structure 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0623 


1 


CS to PS SRVCC access transfer occurs during a call 


11.1.0 


11.2.0 


2012-03 


CT#55 


CP-120120 


0650 


3 


rSRVCC occurs during a call without CS media anchored in 
ATGW 


11.1.0 


11.2.0 


2012-06 


CT#56 


CP-1 20305 


0608 


5 


MSC server state verification procedure solving an EN 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20307 


0657 




URIsforPStoCSSRVCC 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0658 




CS to PS SRVCC - additional URIs of network entities 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0659 




ATU-STI for CS to PS SRVCC 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0661 


1 


CS to PS SRVCC - PS registration 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0662 


1 


CS to PS SRVCC - originating call 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0663 


1 


CS to PS SRVCC - terminating call 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0664 


1 


CS to PS SRVCC, ATGW-anchored element 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0665 


1 


CS to PS SRVCC - access transfer - MSC server procedures 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0666 


1 


CS to PS SRVCC - access transfer - ATCF procedures 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0667 


2 


CS to PS SRVCC - access transfer - SC UE procedures 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0668 


2 


CS to PS SRVCC - access transfer - SCC AS procedures 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0672 


1 


Address the Editor's Note in the flows of rSRVCC without CS 
media anchored in ATGW 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0673 


1 


CS to PS SRVCC - access transfer - MSC server procedures 
when media is not anchored in ATGW 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0674 


1 


CS to PS SRVCC - access transfer - ATCF procedures when 
media is not anchored in ATGW 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20305 


0676 




Incorrect header field for media feature tags 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0677 


4 


CS to PS SRVCC - enhancements of PS to CS SRVCC 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0678 


1 


CS to PS SRVCC - transaction identifier 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0679 


1 


CS to PS SRVCC - flows - transaction identifier 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20304 


0681 


1 


Path header set by ATCF 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20307 


0682 


1 


MSC server registration when the access transfer is 
unsuccessful 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0689 


2 


Definition of feature tag cs to ps SRVCC in alerting phase 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0690 


3 


Addition of UE capability for CS to PS SRVCC in alerting phase 
to PS registration 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0691 


2 


Addition of capability for CS to PS SRVCC in alerting phase to 
CS registration 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0692 


3 


Definition of XML schema for indicating support of CS to PS 
SRVCC in alerting phase 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20297 


0699 


1 


Pay Load type correction - Additional sessions SRVCC 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20304 


0701 




Pay Load type correction - Single (Held or Alerting) session 
SRVCC 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20304 


0703 


1 


Removing one EN about charging and ATCF 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20288 


0707 


3 


Payload type correction - media interworking 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120317 


0708 


1 


CS to PS SRVCC - CS registration 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20307 


0709 


2 


Signalling flows of eSRVCC in case of roaming 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-1 20307 


0710 




Specification clean up 


11.2.0 


11.3.0 


2012-06 


CT#56 


CP-120316 


0711 


1 


Service continuity and support of enterprises 


11.2.0 


11.3.0 


2012-09 


CT#57 


CP-1 20575 


0671 


3 


Use of Feature-Caps header to indicate the support of mid-call 
feature for SCC AS 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20582 


0713 


1 


Reference update and technical changes: draft-ietf-sipcore- 
proxy-feature 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20593 


0714 




CS to PS SRVCC - session transfer cancellation 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20593 


0715 




Minor numbering, spelling and styles corrections 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20593 


0716 




CS to PS SRVCC, alerting and held only 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20593 


0717 




CS to PS SRVCC - PS to CS SRVCC clean up and EN removal 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20593 


0718 


1 


Incorrect info package name g.3gpp.state-and-event-info 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20580 


0722 


1 


Introduction of OMR in SCC AS 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20582 


0727 


1 


Payload type correction - SIP 488 (Not Acceptable Here) 
response 


11.3.0 


11.4.0 


2012-09 


CT#57 


CP-1 20587 


0730 




eMPS for vSRVCC 


11.3.0 


11.4.0 


2012-12 


CT#58 


CP-1 20792 


0734 


1 


Handling of Ixx responses in alerting phase 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20790 


0739 


1 


Removing an EN regarding overlaping procedures 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0740 




Removing EN regarding "related-icid" 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0745 


3 


Correcting PS to PS access transfer 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0746 


1 


Adding the static STI address example in A.2.2 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20792 


0748 


1 


SCC AS handling corrections 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0749 


1 


CS to PS SRVCC, cancellation after preparation 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0750 




Content-Disposition in INFO messages 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0751 




Editor's notes in A. 20.1 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0752 


1 


Editor's note in 12.7.3.1 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20791 


0754 


2 


Feature-Caps header field in target refresh requests and 


11.4.0 


11.5.0 
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responses 






2012-12 


CT#58 


CP-1 20792 


0756 


2 


Originating UE behaviours on the ringing tone when the 
aSRVCC occurs 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0758 


1 


Corrections to signalling flows on originating aSRVCC call 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0760 


2 


Flows for originating call is in alerting phase using SRVCC 
procedure with ATCF 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0762 


2 


Flows for terminating call is in alerting phase using SRVCC 
procedure with ATCF 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-120911 


0763 


2 


Clarification to the SRVCC behavior of non-ICS based UE 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0765 


1 


Editor's note in 6.3.2 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0766 


1 


Editor's note in 12.7.3.2 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0767 


1 


Encoding of media feature tag values of string type in Contact 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0768 


2 


Editor's notes in 12.4.2.2 and A.20.2 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0769 




Editor's note in 12.7.3.3 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0770 




Authorization of early media during SRVCC 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20793 


0771 




Authorization of early media during PS-PS access transfer 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20853 


0778 


2 


SCCF AS Procedures for alerting sessions using SRVCC 
procedure with ATCF 


11.4.0 


11.5.0 


2012-12 


CT#58 


CP-1 20806 


0779 




Incorrect numbering of subclauses 


11.4.0 


11.5.0 


2013-03 


CT#59 


CP-130106 


0781 


2 


vSRVCC behavior of non-ICS based UE 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130102 


0783 


1 


404 and 480 from ATCF 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130116 


0787 


3 


Correction of PS-CS Access Transfer Procedure 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130102 


0789 




Reference update: RFC 6809 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130116 


0796 


1 


Correcting charging correlation 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130112 


0799 




Authorization of early media during CS to PS SRVCC 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130100 


0801 


1 


sec AS capability of MSC server assisted mid-call feature 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130112 


0807 




Incorrect name of Table C.12A-1 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130112 


0808 


1 


Fixing ATCF procedures when no active call exists 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-130103 


0810 


2 


Alerting phase definition and interaction with CAT 


11.5.0 


11.6.0 


2013-03 


CT#59 


CP-1 30097 


0818 




Feature-Tags with "none" value correction 


11.5.0 


11.6.0 
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